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ABSTRACT 


Extravehicular Activity (EVA) is a specialized function performed during spaceflights in 
which two or more astronauts don spacesuits to perform tasks on the exterior of their 
spacecraft. An extensive and iterative planning process is required to prepare for each 
highly choreographed EVA operation. The current planning process relies heavily upon 
time-consuming heuristic approaches by subject matter experts to essentially "hand- 
build" each EVA plan. This research develops the EVA Planning Model (EPM), a linear, 
mixed-integer program intended as a proof-of-concept demonstration for employing 
formal mathematical optimization techniques to EVA planning. The EPM is thoroughly 
tested to verify that it functions as intended and is evaluated by expert EVA planners 
using actual task information. We find that the EPM proves the concept that formal 
mathematical optimization can be used to aid in subject matter experts in EVA 
development and planning. It is particularly useful in allowing the evaluation of 
alternative planning inputs and thorough assessment of EVA plan impacts resulting from 


external changes. 
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EXECUTIVE SUMMARY 


Extravehicular Activity (EVA) is a specialized function performed during 
spaceflights in which two or more astronauts don spacesuits to perform tasks on the 
exterior of their spacecraft. Performing an EVA involves substantial preparatory costs in 
terms of severely limited resources and astronaut crew time. EVA operations also place 
the participants in extreme danger from a multitude of sources. As a result, EVA plans 
must be highly choreographed to achieve the maximum value from each operation. Since 
the advent of EVA capability in the mid-1960s, NASA has used teams of extensively 
trained and experienced subject matter experts from the Mission Operations Directorate 
to carefully plan these activities. They undertake an elaborate and iterative process to 
transform raw requirements from the program customer (currently, the International 


Space Station) into a highly efficient, executable EVA timeline. 


Given the evolutionary development process and repeated re-working of the plan 
required throughout the planning phase, tools that can assist the planning experts may 
result in significant savings or enhanced plan quality. We develop the EVA Planning 
Model (EPM), a linear, mixed-integer program intended as a_ proof-of-concept 


demonstration for employing formal mathematical optimization to EVA planning. 


The nature of EVA planning presents us with a difficult challenge in terms of 
proving model functionality and quality. We address this partly by introducing a 
methodical and thorough testing regimen derived from the field of software engineering 
and adapted to our mathematical model. The proof-of-concept culminates with the use of 
EPM to build EVA plans using actual planning data from subject matter experts. Expert 
opinion surveys are then conducted to obtain an evaluation of the concept and execution 


of the EPM, its usefulness, strengths, and weaknesses. 


Our assessment of EPM and the survey’s results suggest that EPM establishes the 
basis for (and warrants further research on) a formal mathematical optimization that can 
be used to aid subject matter experts in EVA development and planning. EPM creates 


credible EVA timelines that match or exceed the effectiveness of human built solutions, 


XVii 


and allows for trade-off evaluation and "what-if" scenario analysis that can be valuable to 


the planning community in a variety of ways. 


The EPM, as developed in this research, has some significant limitations. Among 
them are (1) a primitive user interface, (2) a lack of functionality in several important 
areas (i.e., robotic arm integration and tool constraints), and (3) highly variable model 
performance in terms of solution times. We recommend future improvements that can be 


made to address these weaknesses and increase the model's capabilities and usefulness. 


XVili 


ACKNOWLEDGMENTS 


Many people contributed to this work both directly and indirectly. I am especially 


grateful to those mentioned here for their aid and support. 


First, my wife Kathryn who has been my guiding light and driving force since 
long before this thesis was begun. During my time as a student at the Naval Postgraduate 
School, she has shouldered the burden of virtually all familial duties in our household 
while working full-time herself. She's the best wife and mother a family could hope to 
have. My daughter, Alexandra, provided motivation and perspective throughout my 
studies. Her conviction that reading a bedtime story with her dad was at least as important 


as him finishing just one more paragraph was a needed reality check. 


I could not have found a better thesis advisor than Dr. Javier Salmeron. He is a 
wizard with mathematical formulation (and troubleshooting) and his devotion to this 
project equaled my own. He responded immediately to my pleas for assistance countless 
times and saved many hours of frustration with his clear and concise guidance. A fellow 
student from NASA, Mr. Dan Mulligan, was a critical partner in defining the initial 
formulation of the optimization model that has been fully developed in this work. Aside 
from that contribution, his exceptional abilities and willingness to help others provided 


inspiration throughout my time at NPS. 


I am also indebted to Mr. Faruq Sabur of the EVA Group at NASA Johnson 
Space Center. He was my point of contact and educator for all things EVA planning and 
went out of his way to help me learn the nuances of the planning job. Additionally, I was 
the beneficiary of Ms. Dana Weigel's knowledge and experience as an EVA Officer and 
Flight Director. Ms. Jaclyn Kagey and Ms. Allissa Battocletti took time out of their busy 


schedules to help me use their EVA as a test case for the model developed in this thesis. 


Finally, I would like to thank Dr. Wally Owen, who made a place for me in the 
Joint Executive Systems Engineering Management program. It has been an incredibly 


challenging and enlightening experience which will provide me with lasting benefit. 


X1X 


THIS PAGE INTENTIONALLY LEFT BLANK 


XX 


I. INTRODUCTION 


Extravehicular Activity (EVA) is a specialized function performed during 
spaceflights in which two or more astronauts don spacesuits with self-contained life 
support systems (extravehicular mobility units or EMUs) to perform tasks outside of the 
spacecraft. These tasks range in purpose from the deployment or retrieval of scientific 
experiments to vehicle maintenance or assembly. The standard EVA is a 6.5-hour-long 
operation (limited by EMU consumables and crew endurance) in which two crew 


members perform a series of tasks as outlined in a detailed plan. 


Since Ed White performed the first U.S. spacewalk in June 1965 (Portree & 
Trevino, 1997), the National Aeronautics and Space Administration (NASA) has made 
tremendous advances in techniques, support equipment, and operations related to EVA. 
The construction and maintenance of the International Space Station (ISS) has relied 
heavily upon the use of EVA. To date, 127 U.S. EVAs have been conducted in support of 
the ISS assembly and its on-going mission. The design of the vehicle is such that EVA 
operations will continue to be a frequent and critical part of its upkeep for the life of the 


program, projected to extend to between the years 2020 and 2028. (NASA, 2010a). 


Though NASA has leveraged its 47 year history with EVA to build a record of 
overwhelming success throughout the ISS program, there are still areas with potential for 
improvement. In particular, the planning of EVAs remains a very labor-intensive process 
which relies heavily on individual expertise and multiple iterations between different 
stakeholders. In effect, each EVA is hand-built by a team including the Mission 
Operations Directorate (MOD) flight controllers, the astronaut crew, and the EVA Project 
Office. 


A. HIGH LEVEL PLANNING PROCESS 


The normal process of planning an EVA takes several months and generally 


includes the considerations discussed in the following subsections. 


if Overview of the Planning Process 


There are several phases in the planning process from conception to execution. 
Depending on the program, mission, and situation, the need for an EVA can generally be 
categorized into three groups: those driven by a single high priority task, those composed 
of a collection of tasks built up on a "to do" list, and those necessitated by a vehicle 


system failure or other contingency situation. 


Once a need is identified, the customer program generates requirements (in the 
form of tasks), prioritizes them, and organizes them into their best estimate of EVA-sized 
groups. These requirements are evaluated by the MOD planners who create draft 
overview timelines for an individual, or series of EVAs. This process is an iterative, 
back-and-forth exchange in which the planning experts generate a first heuristic timeline. 
Any proposed alterations to the initial allocation or prioritization of tasks which may 
have an impact on the plan must be negotiated between MOD and the customer program 


office. 


Once a basic mapping of tasks to a given EVA is completed, the planners will 
subdivide and order tasks to maximize efficiency of the plan. Many considerations are 
taken into account in this process: the locations of tasks, required support equipment, 
availability and location of spare parts and tools, translation times and paths from one 
task to another, astronaut body positioning, lighting conditions, hazard controls, etc. 
These considerations result in a draft of a detailed plan which has a high level 
representation called a summary timeline. When this is developed, the astronaut crew is 


introduced to the plan and training begins. 


Although the activity is called training, it is equal parts practice for the crew and 
further development and refinement of the plan. Several facilities are utilized in this 
phase of development, starting with basic desktop review and proceeding to the more 
elaborate Virtual Reality Lab to practice fine, close-up work and spacial relations. 
Simultaneously, training is conducted in the Neutral Buoyancy Lab (NBL) for full dress 


rehearsal. The active response gravity offload system is a facility that helps the crew 


practice body control and manipulating masses in zero-gravity. Other training aids, such 
as an air bearing floor and camera and photo labs are used to help the crew practice more 


detailed facets of EVA. 


Throughout the training phase, the EVA timeline is constantly refined as data is 
gathered on the duration of tasks and potential issues are noted. In some cases, a better 
understanding of the time duration of tasks and their interactions could lead to the 
removal or addition of tasks to the plan. The planners are constantly gathering data from 
the training exercises and the other coordination processes that are concurrent. There is a 
continuous flow of detailed requirements related to interfaces, hardware, and special 


constraints. The plan is filled out and iterated throughout this period. 


The above description is a simplified look at the high level steps in the planning 
process, but it is important to realize there is much more complication in the planning 
process than can be presented here. Many layers of detail underpin the creation of an 
executable EVA plan. A simple example of the increasing levels of detail considered as 
the plan matures is what the planners call "bag-ology." This is the pseudo-science of 
planning the contents, packing, use, transportation, deployment, and management of the 
storage bags the crew will use during the EVA. Understanding what equipment, tools, 
and spare parts must be placed in bags, how and when they will be used, and how and 
where they can be temporarily stowed is an exhaustive process. It alone can take many 
hours of research, development, training runs, and iterations to finalize. Similarly detailed 
work is required to incorporate hazard analysis, orbital replacement unit (ORU) mass, 
center of gravity, and moment of inertia data, equipment jettison protocols, tool settings, 


tether "tie downs" to restrain lose equipment, predicted solar radiation conditions, etc. 


The final phase of the process is execution. This phase is the most time- 
compressed and dynamic. Crew performance can exceed expectations, creating free space 
to accommodate more tasks, or problems could arise, forcing a restructuring of the 
remainder of the in-progress EVA or of subsequent EVAs. In-progress re-planning is the 
most time-critical aspect of the process and has the potential for the most gain, but also 


the most risk in terms of opportunity cost. 


Figure 1 shows the basic flow of the planning process. This thesis is concerned 
mainly with high-level planning, thus many of the intermediate process details are 


omitted from the flow chart. 
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Figure 1. Simplified EVA Planning Process Diagram 


2. Planning Considerations 


Cost is a primary consideration in planning an EVA. A start-up cost results partly 
from the need to physiologically condition the crew for the low pressure, 100%-oxygen 
environment of the EMU suit. Four different pre-conditioning protocols (called pre- 
breathe) have been approved and employed, but all of them use oxygen and nitrogen 
stored in high-pressure tanks aboard the ISS and a significant amount of crew time 
(Brown & Jarvis, 2011). Although the ISS has systems to recover much of the 
atmospheric gas that would otherwise be vented overboard during depressurization of the 
airlock, the air that is not recovered is a factor in the cost as well. Gaseous resources like 
oxygen, nitrogen, and air must be fastidiously conserved aboard a long duration vehicle 
such as the ISS and will be even more critical on any future deep-space platform. 
Approximately 12 kilograms of oxygen is expended from the ISS high-pressure gas tanks 
for each EVA. Crew time is also an important resource aboard the ISS, where every 
minute spent on systems maintenance or tasks like EVA preparation takes away from 
time devoted to scientific experiments. The investment for pre-breathe, which is in 
addition to the time required for tool, equipment, and self-preparation, can range from 


four hours for the "in-suit" pre-breathe to an overnight "campout" protocol that stretches 
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over two crew days. The time cost is also very significant on the days and weeks prior to 
the EVA. Suit checkout, maintenance, and fit verifications, tool preparation, battery 
charging, water filterig, and planning conferences with mission control add significant 


time as well. 


It must be considered that all gaseous consumables used for EVA preparation 
must be brought to Earth orbit. As a result of high launch costs, estimated by the U.S. 
House of Representatives Subcommittee on Space and Aeronautics at approximately 
$20,000 per pound (NASA's Commercial Cargo Providers, 2011), these resources, along 


with crew time, must be spent very wisely. 


Another factor in EVA planning is the relatively high risk of these operations. The 
spacewalking crew is working in the most hazardous and hostile conditions. Some of the 
risks are environmental, such as the vacuum of space, extreme temperatures, radiation, 
and micrometeoroid and orbital debris impacts. Other risks are occupational, related to 
the work and equipment: suit snags and leaks, entanglement, hazardous materials, loss of 
positive contact with the vehicle or tethers, handling massive objects, and EMU suit 
systems malfunctions. All of these risk factors can lead to serious injury or death for the 


crew. 


These costs and risks drive some basic guidelines for planning. First, all EVA 
operations are planned to utilize the maximum duration of EVA time and minimize the 
total number of EVAs to accomplish the required tasks. Second, all time outside the 
vehicle is considered precious and every minute must be planned to maximum effect. 
Third, all EVAs must have at least two crew members to allow for a "buddy system" in 
case of emergency. Additional planning considerations are employed to address these and 
other costs and risks, many of which will be discussed in detail in the planning model 


formulation presented in Chapter IL. 


3. Special EVA Planning Driver: Big 12 Failures 


One special case of requirements generation shown in Figure 1 deserves special 
attention. Block la shows that EVA requirements can be driven by vehicle systems 


malfunctions. With the ISS at the "assembly complete" phase, one of the biggest drivers 
5 


for EVA is the potential for systems failures which require removal and replacement of 
ORUs on the exterior of the vehicle. The ISS program has identified 12 contingency 
EVAs which would require relatively immediate implementation. Each EVA corresponds 
to the resolution of a specific ORU or functional failure aboard the ISS and this list of 
EVAs (and/or their triggering failures) has been dubbed the "Big 12" by the ISS 
operations team and program. Criteria to be included in the Big 12 is formally described 
by the ISS program as "the failure of the function provided by the ORU causes a situation 
placing the ISS in a configuration that is zero fault tolerant, or effectively zero fault 
tolerant, to survival" (NASA & Roscosmos, 2011). The ability to handle the Big 12 
failures via EVA repairs is such an important concern that it is currently one of the top 


four program risks identified by the ISS Program Risk Advisory Board (Uhran, 2012). 


Since the failure modes are known, these EVAs can be planned to a basic level 
ahead of time, but the uncertainty of when they might occur drives many planning 
complications. The unknowns are many: the crew members who will perform the EVA, 
the condition of the vehicle, the status of supporting equipment and systems (such as 
robotics), any secondary schedule drivers (such as the impending arrival of a resupply 
vehicle), any other outstanding tasks that could be added to a Big 12 EVA, etc. The 
uncertainty puts tremendous pressure on the planning process, which must be accelerated 
significantly to address the urgency of the situation. On July 31, 2010 an external thermal 
control pump module failed aboard the ISS (a Big 12 failure), driving the need for three 
contingency EVAs to replace it. The first of these EVAs was executed just six days after 
the malfunction, the second and third followed in the following nine days (NASA, 
2010b). Clearly, such an intensive sequence of operations stresses the planning process in 


the extreme. 
B. SUMMARY TIMELINE DEVELOPMENT 


One of the first steps in the planning process is to arrange tasks into groups that 
conceptually represent EVAs. As noted in Figure 1, the program customer begins the 
process by identifying tasks and assigning relative priorities to them. The program then 
estimates the task durations and produces a conceptual EVA which is simply a collection 


of tasks they expect will fit into one or more EVAs. MOD takes this input and applies the 
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first of many evaluations to its feasibility and efficiency by creating a summary timeline 
(sometimes called an overview timeline). The effort required to produce a summary 
timeline requires approximately one week for one to two experts. It is the basis of 
iteration in the planning process and may be repeated, in part or as a whole, several times. 
This iteration is essentially an education and negotiation process for the program 
customer whereby task priorities and groupings can be debated on the basis of the 
efficiency of the resulting EVA. This process continues as the planners work through the 
steps in Figure 1. Often, new information or changes late in the process can lead to 
renegotiation with the program customer, resetting the process back to a very early stage. 
Thus, many summary timelines may be built throughout the development of a single 


EVA. 


Figure 2 shows three examples of summary timelines for EVAs that have either 
been completed or are in the planning stage. The format shown is one of several used 
regularly in EVA planning and will be used throughout this research. Two rows in each 
graphic represent the task assignments for each of the crew members, always designated 
EV1 and EV2, respectively. Phase elapsed time (PET), a measure of time that begins 
when the crew exits the spacecraft, increases to the right. The top timeline is for a 
nominal EVA, meaning it contains tasks which are driven by planned program 
requirements rather than a need to address equipment failures. The second timeline is for 
a similar nominal EVA, but one which does not have enough tasks to fill a full, 6.5-hour 
EVA. This can happen if there are not enough tasks in the queue when an EVA is 
scheduled or because the planners are especially concerned that some tasks could take 
longer than planned. As a result, time is left in the plan for so-called "get-ahead" tasks. 
This allows the EVA flight controllers to slot additional tasks into the extra time in near 
real-time as long as the scheduled tasks do not run over time. The third timeline is for a 
contingency EVA, one that would only be performed as a response to a system failure or 
other unplanned event. As can be typical for this type of EVA, the planned tasks do not 
run the full allowable duration, leaving open the possibility of adding other tasks to the 


timeline in near real-time. 


The remainder of this section elaborates on details that must be considered 


whenever a summary timeline is generated. 
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Figure 2. | Examples of Summary Timelines 
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1 Task Priority 


Generally, tasks will be ordered in an EVA timeline with deference to their 
priority. Scheduling the highest priority tasks first gives the highest probability of 
completion of those tasks in the event the EVA must be terminated early due to suit 


malfunctions or other problems. 


There are cases, however, where performing a lower priority task first creates a 
valuable time efficiency or reduces idle time. As such, the schedule cannot be driven by 
priority alone. The process of summary timeline creation can identify situations like this 
which usually provide useful data to inform a renegotiation with the program customer to 
ensure they understand the benefits and shortcomings of scheduling tasks strictly in 


priority order. 


2. Task Duration 


Each task is assigned an estimated duration when it is first proposed. Refining this 
duration is one of the goals of the training and development process. This refinement has 
parallels to cost estimation in a normal program development process. In some cases, the 
task (or a similar task) will have been performed previously, allowing the planner to 
consult a database of actual duration information for a specific task. As each task is 
practiced in the high fidelity simulators, the understanding of its duration is improved 
further. Up to three NBL runs are dedicated to task and timeline duration validation in 
normal circumstances, with the possibility of more if the tasks and procedures are 


immature or untried (Brown & Jarvis, 2011). 


Once enough data are available to make good estimates of task durations, several 
modifying factors are considered. A skill rating is assigned to each crew member based 
on their background, experience, and aptitude level. This rating is used to adjust the time 
required for tasks, especially in cases where the crew performing the EVA are not the 
same astronauts who participated in the ground training. Another modifier is a 
multiplication factor applied to task durations derived from 1-g training. Experience has 


shown that tasks simply take longer when performed in the microgravity environment of 
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space and working with actual flight hardware. Depending on the task, this multiplier 
could double the expected time to complete the same task on-orbit as compared to 1-g 


training. 


3. Task Location 


The ISS is a vast structure in space vehicle terms. It is roughly the shape of a 
cross, with a 109-meter truss extending along one axis and a 51-meter axis containing the 
pressurized modules (NASA, 2011). Practically any location on the exterior of the ISS 
could be an EVA worksite, but typically worksites will be centered at the locations of 
installed equipment (i.e., ORUs). To give a general understanding of the magnitude of the 
number of possible worksites, Figure 3 shows the locations of all ORUs installed on the 
truss segment. Each red circle and pointer represent one installed ORU on the truss. 
There are many more worksites on the exteriors of the pressurized modules which are not 


shown in this diagram. 
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Figure 3. Truss ORU Map (from NASA, 2010c) 
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Task location is important because the crew must move from worksite to worksite 
in order to perform their jobs. This movement is typically a manual "crawling" from 
place to place but can also be aided by the robotic arm. Navigating across possibly 
sensitive equipment, avoiding snag hazards, managing body position, observing proper 
tether protocol, and ingress or egress of portable foot and body restraints contribute to the 


time required to move from one location to another. 


4. Task Precedence 


Tasks must be ordered properly to comply with any prerequisites that must be 
completed before a given task may be undertaken. Precedence relationships between 
tasks can be the result of a physical need, or be stipulated by the planners in order to gain 
efficiencies. An example of the former is disconnecting electrical connectors before a 
piece of equipment can be removed. In the latter type, planners may consider operational 
reasons, such as waiting to retrieve a replacement part until the old one is successfully 
removed. Otherwise, if unforeseen problems prevent the removal of the old part, any time 


spent retrieving the new one will have been wasted. 


ne Task Synergy 


Some tasks may be much easier or quicker to perform if they are scheduled either 
in conjunction with or following other specific tasks. For example, consider a task which 
has no mandatory predecessors, but would take 50% less time if performed following 
another task. Benefitting from this type of efficiency works hand-in-hand with non- 


binding task precedence as described in the previous sub-section. 


6. Special Task Timing Requirements 


Some tasks have special timing requirements which must be taken into account in 


planning. Some examples are: 


a. Day/Night Constraints 


The orbital speed of the ISS leads to a unique work environment in which 
the sun rises and sets every 90 minutes. This results in four day and four night periods 
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during the typical 6.5-hour EVA and has an effect on both the lighting and thermal 
conditions that can impact task timing. Some tasks can only be performed in daylight or 
only in shadow, and some others must be timed such that they do not cross a day-night 
boundary. Fluid connector mate or de-mate is an example of a task that should not be 
performed across a day-night boundary because the large temperature swings can cause 


"hydraulic lockup" of the connector as pressure changes inside the fluid lines. 


b. Thermal Clocks 


Thermal constraints are of considerable concern. Most electrically 
powered exterior ORUs have rigid temperature constraints that are met only when the 
equipment is powered or supported by heaters. EVA crews routinely have to remove 
power from, and relocate these devices. As soon as power is removed, a so-called 
"thermal clock" begins ticking down to the ORU's lower temperature limit. The time 
window allowed before power must be re-applied is provided by engineering analysis 


prior to the EVA. 


Cc. Support Systems Interaction 


Many tasks require support from other systems on the vehicle. Typical 
interactions include: de-energizing an electrical bus before the EVA crew disconnects a 
wire, stopping the rotation of the moving equipment near the crew's work area (such as 
the large rotary joints that point the ISS solar arrays and thermal radiator panels), or 
deactivating high power antennas that cause a radiation hazard to the crew when they 
enter specific areas. Most of these supporting tasks are performed by the crew inside the 
vehicle, called the intra-vehicular activity support crew, or by flight controllers on the 
ground. In either case, there may be timing constraints on performing the necessary 


supporting actions for a given task. 


Some support system interactions could impact the timeline in the form of 
wait times. For instance, a new segment of thermal control tubing must be vented of its 
nitrogen pad before being connected to the flight system for the first time. In some cases, 
the crew may have to wait for this process to complete and, in other situations, it may be 


possible to continue with other tasks during the wait period. 
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d. Possibility of Suit Contamination 


The ISS utilizes several highly toxic substances in its systems. This 
includes pure anhydrous ammonia and hydrazine propellants. In cases where the EVA 
crew must interact with these systems, there is a possibility of suit contamination from 
leaks. If an EMU suit comes in contact with a toxic substance, it must be decontaminated 
before it comes into contact with the ISS cabin atmosphere. MOD has developed a 
protocol called "bake-out" which is performed prior to airlock ingress and 
repressurization in cases where contamination is suspected. Bake-out requires the crew to 
use a brush to remove any crystals from the suit and then expose themselves to direct 
sunlight for a predefined period of time to heat any remaining crystals enough to 
sublimate off the suit. This is a fairly lengthy process which must be accounted for by 
scheduling tasks with a risk of toxic contamination early enough in the EVA to allow 


enough time for its completion in the event contamination occurs. 


e. Break Out Points and Bingo Times 


For tasks that could leave a component or system in an unsatisfactory 
condition if they are not completely finished, breakout points are identified based on the 
specific activities involved in a task and its predicted duration. A breakout point can be 
thought of as the point of no return during a task: a decision point to continue or abort the 
task based on how much time is left in the EVA. Tasks which cannot be segmented in 
this fashion, but carry the same risks if not completed, are assigned so-called "bingo 
times." A bingo time is the latest point in the EVA where the task can be started and still 
maintain a high probability of completion. Breakout points and bingo times are carefully 


evaluated as risk trades by the MOD team and the community of stakeholders. 


7. Tandem Tasks 


For the purposes of this thesis, we consider only the most common case of two- 
person EVAs. A substantial number of the possible tasks that could be assigned during 
these EVAs require both crew members to work together. The need for two 


crewmembers to perform a task can be driven by, for example, a need to maneuver or 
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hold in place unwieldy or massive equipment. The timeline must accommodate both crew 
members being in the correct location during the same time period to accomplish tandem 


tasks. 


8. Tool Requirements 


Most tasks require that the crew use one or more tools. Many tools have been 
developed for use by EVA crewmembers, ranging from pry-bars to zero-torque bolt 
drivers and cameras. Deployment, transport, and use of tools are important factors in 
EVA planning. Planners must ensure that the crew has the right tools packed in their bags 
before leaving the airlock, that tool sharing is accounted for if required, and that tool 


movements and temporary stowage are properly handled. 


9, Subdivision of Tasks 


Part of the heuristic nature of current EVA planning is in the subdivision of tasks. 
A given task may contain one single objective but require many steps to complete. These 
sub-tasks are not strictly defined by default and their nature may be optimized by the 
planner throughout the development and training process. A simple example of 
subdivision can be observed in the LEE R&R (Latching End Effector Removal and 
Replacement) EVA summary timeline (shown as the third timeline in Figure 2). 
Depending on how detailed the program customer task data is, the planner may receive 
several sub-tasks or just one task, "Replace Failed LEE," as an input for this timeline. In 
the case where few detailed tasks are given, the planner must subdivide the larger tasks 
into steps which can then be planned individually. Examination of the LEE R&R timeline 
in Figure 2 shows there are multiple individual tasks identified to perform the objective 


and demonstrates the level of subdivision that is typically done by the planners. 


The subdivision may be based on any number of factors just a few of which 
follow. Tasks may have natural break-points that could be used to subdivide them, such 
as moving to a new worksite, changing tools, or altering tether points. Other drivers may 
be based on the elimination of wait times that could be part of larger tasks (for instance, if 


only part of the task requires two crew members). 
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C. PROCESS IMPROVEMENT AREAS 


MOD's flight controllers and planners often find themselves in the position of 
having to call a halt to a seemingly never-ending string of minute improvements to their 
plans and products with the phrase "better is the enemy of good enough.” Ultimately, 
they are preparing for events that will happen on a rigid schedule. Missions and 
operations will not wait while the next incremental improvement is made. In this light, it 
is difficult to claim that improvement is needed with respect to EVA planning. The 
success of currently employed methods cannot be disputed. NASA has approached, and 
no doubt in some cases achieved, a maximization of the potential of each EVA 
opportunity. However, we believe there are ways to improve the process while also 
making it faster. Below, we detail some of the challenge and risk areas for the current 


process. 


1. Cost, Schedule, and Experience Requirements 


The process described in Section B is very labor-intensive as every step in it is 
completed by hand. This, in turn, demands highly skilled and experienced personnel. The 
typical EVA lead planner from MOD has five to ten years of training and experience. 
This caliber of engineer is a very costly resource. Additionally, since the structure of the 
organization is such that the same group of people perform the planning, crew training, 
and all other stages of EVA development, there is a zero-sum game aspect to work 
planning. Any off-loading of effort from the highly skilled MOD workforce can free 
them up to perform the work that truly demands their expertise. In other words, applying 
their expertise to evaluating plans rather than drafting them. Developing and refining 
high level timelines needed every time tasks, durations, or priorities are updated could be 
streamlined. Automation to a degree that can allow the expert to focus on the outcome 
rather than the tedious work of task ordering and basic constraint de-confliction would be 
a valuable benefit. Moreover, as the process involves several iterations of these 


development phases, the payoff of automation is multiplied. 
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25 Production Speed 


As a corollary to the labor-intensive nature of current EVA plan development, the 
process is slow to navigate. This has several impacts at different points in the process. 
Early on, it prevents the evaluation of many different timeline options. Later in the 


process, it restricts the ability to deal with late-breaking changes or perturbations. 


There is constant change occurring throughout the EVA development cycle, 
especially as it relates to ISS, a continuous mission. This change can take the form of 
priority changes, new tasks being added to a plan, other tasks being deleted (for lack of 
hardware or other reasons), or even change of crew members who will be performing the 
EVA. Further, support equipment can fail or be lost, keep-out zones can be added or 
changed, or changing environmental factors such as solar beta angle can force changes to 
tasking or timing. Some of these factors can impact an EVA just days prior to planned 
execution (see Section II.E.2 for a more complete explanation of uncertainty in sunlight 


conditions). 


The Big 12 EVAs discussed earlier are a prime demonstration of the utility of a 
rapid prototyping capability for EVA planning. Even though the pump module 
replacement conducted in 2010 shows that the current process is capable of dealing with 
such situations, the ability to create multiple evaluation-ready draft overview timelines in 


minutes or hours would significantly help the planning team. 


Even more impactful are changes that occur in real-time during an EVA. Many 
times, problems with a task early in an EVA may prevent the completion of tasks planned 
for later. Other times, the crew gets ahead of the timeline and there may be free time that 
can be utilized. The MOD team does plan for these situations, but in order to maximize 
the efficiency of EVAs, a full accounting of all possible changes must be done. There is 
rarely time for such a complete examination. Choosing which tasks to add to an EVA that 
is ahead of schedule or delete from one that is behind is hardly done haphazardly, but the 


decisions could be more informed if basic planning decisions could be tested rapidly. 
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3. Limited Ability to Assess Options 


Flowing out of the first two limitations is the fact that only a small number of 
options can be evaluated for a given EVA. In some cases, there are only a few tasks on 
the program's list and slotting them into a given EVA is easily done. However, in cases 
where there are more tasks than could fit into a single EVA (or multiple EVAs if a series 
is being planned), the experts cannot assess all possible combinations of task selection. 
Once tasks are selected, their ordering during the EVA is the next decision. Once again 
there are cases where this is self-evident, but also many where discretion can be applied. 
Even a relatively limited list of tasks can have a very large number of combinations, far 
too many for a planner to investigate comprehensively. An automated tool for optimal 
task selection and ordering would improve the quality of the resulting EVAs by 


combining the two decisions into one. 


In summary, such a tool would be a very powerful ally in negotiations with the 
program about task prioritization and placement. It would also find much use throughout 


the iterative process of plan development and even possibly in real-time operations. 
D. RESEARCH GOALS 


The goal of the research documented in this thesis is to investigate the feasibility 
of utilizing combinatorial optimization to improve the efficiency of EVA timeline 
development. Specifically, we seek improving the current EVA planning process in: (1) 
the time required to develop a timeline, (2) the thoroughness of trade-space evaluation, 
and (3) the verification (or simplification) of rule and constraint compliance. We have 
introduced the planning process as one that involves substantial effort and broad scope. It 
requires much in the way of individual expertise, experience, and hands-on development. 
Our goal is not to create a solution that nullifies this expertise, but rather enhances it by 
alleviating the considerable burden of developing initial timelines and by allowing the 
evaluation of many more potential combinations of tasks than is possible today. We 


further intend to understand how useful such a tool might be throughout the planning 
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process and its many iterations from first timeline through the execution phase. Any 
examination of the benefits of a solution must also investigate its limitations and we 


include this in our study as well. 


We also intend that by focusing our solution on workload reduction for the EVA 
planners rather than attempting to create a turn-key plan development tool, our model 
will meet with greater acceptance in the user community. This is critical if any result of 


this research is to be pursued to assist in future EVA planning. 
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I. EVA PLANNING MODEL 


This chapter details the development of the EVA Planning Model (EPM). We 
begin with a survey of some classical problems and techniques in the operations research 
literature to put the EVA planning problem in context and to justify our approach to the 
problem. Requirements for the model are outlined in Section C, and addressed in the 


EPM's formulation developed in Sections D and E. 
A. MODEL CONTEXT 


The goal of the EPM is to create the optimum EVA plan, which to the first order, 
is the one that maximizes the priority of scheduled tasks within the allowable time. The 
EVA planning problem has three major sub-parts: selecting which of the available tasks 
will be placed into the timeline, assigning those tasks to one of the crew members, and 
ordering the tasks. Clearly, these three sub-problems cannot be addressed individually in 
series because each one must be considered with respect to the other two. We must also 
understand that priority alone does not dominate the decision making in EVA planning. It 
coexists with efficiency which can be conceptualized in pseudo-units of priority per time 


unit per task. 


Solving the problem of translating customer requirements (in the form of tasks 
and relevant task data) into the best possible EVA timeline can be informed by utilizing 
aspects of and concepts from several classical combinatorial optimization problems in the 
operations research literature. This section puts the EVA planning problem into context 


by drawing parallels to these classical problems. 


1. Knapsack Problem 


In its simplest form, the knapsack problem assumes a given a set of items, 


J €{l,2,3,...n}, where each item j has a value, Pj} and a weight, W,. The problem is to 


determine the optimal combination of items to maximize the total value which can be 
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carried in a knapsack of limited weight capacity, c. Binary variables, x, are introduced 


to indicate whether or not a given item has been selected. The mathematical formulation 


is as follows (from Martello, 1990): 


Maximize Z = oy DX; 


j=l 


n 
< 
S.t. Y wx; SC, 
j=l 


%, {0,1}, Vj 


The planning drivers for EVAs can vary as discussed in Chapter I. In situations 
where the goal is to construct the best possible EVA from a collection of prioritized tasks 
identified by the program, task selection is a critical part of the solution. The knapsack 
problem is a perfect analogue to this and provides us with a guide for the task selection 


sub-problem. 


We can adapt the knapsack problem by substituting tasks for items, priority for 
value, and duration for weight. Our constraint is the maximum allowable length of the 
EVA. It can also be associated with a situation where an existing EVA timeline has some 
Spare time, or "white space," available and we must select from amongst a group of 


candidate tasks to fill it. 


This adaptation allows us to use the knapsack problem formulation as a base upon 
which to build our task selection model. We must, of course, still concern ourselves with 
several intricacies of task selection imposed by the remaining two intertwined sub- 


problems. 


2. Travelling Salesman Problem 


The travelling salesman problem (TSP) applies so naturally to a variety of 
business and travel endeavors that it has been contemplated since long before operations 
research became an organized field. Published non-mathematical formulations of the 
problem date back to at least 1832 (Schrijver, 2005). As summarized by Laporte (2010), 


it considers the problem of a salesperson whose region contains n cities which must all 


Ze 


be visited exactly once before returning to the home city. The goal is to minimize the 
total travel distance or cost while still visiting each city. The problem can be visualized 
more easily as a simple network graph as in Figure 4. The distance between each city pair 


(i, j) is denoted by L, ;. Travel distance is equal between two nodes regardless of travel 


direction and all nodes are connected. The path taken by the salesperson through this 


network is called a tour. 

















Figure 4. _ Basic travelling salesman problem network 


Routing is a major factor in EVA task selection, assignment, and scheduling 
because the ISS is a large structure with widely distributed worksites. Since each 
astronaut must physically move from their current location at any time to the location of 
their next assigned task, there is a time penalty associated with scheduling adjacent tasks 
at locations separated by long distances. While this aspect of the EVA planning problem 
is a textbook instance of the TSP as described above, it has several considerations that 
make it a unique variation of the simple TSP. Figure 5 shows a network model more 


appropriate for the EVA case. 


23 







T,. v \ 

Airlock,N ' , 

SORE a BSS, EES SIE Sy ea | Worksite: 
Tess, \ 

N,Airlock 7a, N 


Tp airlock Tan 






T pirlock,B 





T airlock Ty airlock 








Figure 5. | EVA planning problem as an asymmetric TSP network 


There are several noticeable differences between the network arrangements in 
Figures 4 and 5 that hint at some of the complications of applying TSP methods to 
optimizing crew movement. Note that the EVA problem includes two time costs: the time 


to move (or translate) from node i to j, and also the time required to perform the task at 
j. The arc costs, T;, “i in Figure 5 are the sum of these two costs. Observations about the 


EVA problem as it relates to the TSP follow: 


(1) Asymmetry. The EVA network in Figure 5 is asymmetric. There may be a 
different cost to travel between two nodes depending on which direction is traversed. 
This is because the EVA case is expressed in units of time, which is the travel "cost" of 
the EVA planning problem (as opposed to distance or money). Even if we ignore the task 
duration caveat noted above to separate translation time and task duration, the time 
required to travel between any two nodes in the EVA case is still asymmetric. The 
physical translation time between worksites, which may or may not be aided by robot 
arm support, is the sum of the movement time and the time it takes for the astronaut to 
properly restrain himself at the new location. This can involve setup and ingress of an 
adjustable portable foot restraint, configuration of a body restraint tether, or a number of 
other tasks. Since the crew support interfaces can vary by worksite, the travel cost of a 
given arc in Figure 5 is dependent on the destination node and thus the EVA problem 


involves an asymmetric TSP (ATSP). 
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(2) Dynamic Nodes. We do not have a static set of nodes (worksites) in our 
network. Worksites are associated with tasks and task selection is part of the overall 
problem. If we stipulate that all tasks must be completed, the EVA routing sub-problem 
reduces to a generic ATSP network, but we need to allow for tasks to be omitted if they 
are not part of an optimal solution so a complete network does not exist until the problem 


is completely solved. Figure 5 depicts this with the dashed node, J . 


(3) Multiple Agents. We have two crew members visiting the worksites associated 
with the tasks, thus making this a multiple TSP, with the additional complication that 
some tasks require synchronization of both crew members. Therefore, the goal is not 
simply to divide all the worksites or tasks among the two crew members so that each is 


visited or performed once and only once. 


(4) Redundancy. An EVA plan does not restrict repeated visits to the same 
location. The basic travelling salesman problem stipulates that each node (with the 
exception of the source node) be visited only once. This constraint is not appropriate for 
EVA for various reasons: task precedence relationships and the inclusion of tandem tasks 
may stipulate that a worksite be visited several times. Alternatively, we may never visit 
certain worksites or perform certain tasks. To constrain movement (or task selection) 
such that each worksite must be visited exactly once would severely limit the usefulness 


of the resulting EVA plans. 


(5) Multiple Task Locations. Although an EVA plan can be generally visualized 
by use of network diagrams as in Figure 5, the interweaving of tasks and locations makes 
the true meaning of the nodes ambiguous. Since tasks are inherently associated with 
worksites, a node could ostensibly represent a worksite location or a task; however, some 
tasks occur at multiple worksites and thus a crewmember may arrive at a particular node 


to begin a task and leave from a different node at its completion. 


(6) Time Windows. Constraints on lighting, interfaces with support systems, 
ground communications, and other concerns can force tasks or worksites to be off limits 
at certain times. These type of constraints are partially represented in the time-window 


variant of the travelling salesman problem, but non-standard specifications of those 
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constraints are required in the EVA case as will be discussed later in this document. 


Figure 5 denotes the existence of time windows with dashed arcs. 


(7) Precedence. Precedence relationships exist between many tasks. This results in 
what amounts to a combination of time windows but the restriction extending to pairs (or 


sequences) of nodes rather than just single nodes. 


3 Dynamic Programming Problem 


Imagine the EVA sequencing sub-problem as one of slotting tasks into a series of 
stages, k e€ {1, 23K |}. This conception of the problem is depicted in Figure 6: nodes 


represent possible tasks, and each arc has a transition “cost” equal to the time it takes to 
translate from one worksite to another, plus the time it takes to perform the second task. 
Since we know that every EVA starts with airlock egress and ends with airlock ingress, 
those nodes are fixed, and the problem aims to select which task is placed into a given 
stage in order to create a sequence that minimizes completion time of all tasks, similar to 
a shortest path problem. All other nodes in the network are based on the tasks available 


and are a result of the task selection sub-problem. 







A/L A/L 
Egress Ingress 


Stage 1 Stage 2 Stage 3 Stage 4 Stage k 


Figure 6. | EVA planning problem as a shortest path network with stages 
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It is worth noting that the EVA planning problem, when conceived as described 
above, resembles a dynamic programming problem. The characteristics of these problems 
(see, e.g., Winston (1987)) are: (1) the problem can be divided into stages with a decision 
required at each stage; (2) each stage has a number of states associated with it; (3) the 
decision made at any stage describes how the state at the current stage is transformed into 
the state at the next stage; (4) given a current state, the optimal decision for each of the 
remaining stages must not depend on the previously reached states (known as the 
principle of optimality, see Bellman, 1954); and, (5) there must be a recursion function 
any stage, k, and state, i, that provides costs associated with the next stage, k+1. 
Figure 6 shows that we are able to divide the problem into stages and that the tasks 
(which include task specifications such as location, duration, etc.) represent the states for 
each stage. The decision of which arc to follow from each state defines a transition to the 


next stage and state. 


However, there are several factors that make the actual EVA problem more 
difficult than that of Figure 6. The first complicating factor is that the number of stages in 
the network is not a constant, but varies based partly on both the number of tasks under 
consideration and their durations. Our desire to allow all tasks to be represented as states 
in all stages of our network, to be eliminated from subsequent stages, k +1, k +2,...K , if 
selected in stage k, would violate the principle of optimality. Each stage should contain 
any task which has not already been completed (or ruled out by other constraints such as 
task precedence). That dilemma also threatens the possibility of creating a recursion 
function. Finally, additional complications arise given that there are two crew members 


performing tasks simultaneously during an EVA. 


4. Job Shop Problem 


Among the classical problems in operations research, the job shop is a well- 
known model employed for sequencing tasks. This section discusses the basic tenets of 


the job shop problem and its application to EVA planning. 


Zh 


a. General Description of Job Shop 


The job shop problem, is primarily a scheduling optimization problem 
formulated for manufacturing, production, or similar operations (see, e.g., Nahmias 
(2009)). The generalized setup of the problem is a manufacturing floor or assembly line 
with machines that perform actions on "jobs" that arrive at the plant. Jobs have a duration 
(also called processing time) and a due date. This results in a need to identify the 


sequencing that will result in the most efficient use of resources. 


b. Static and Dynamic Variants 


The arrival pattern of jobs can be either static or dynamic. In the static 
scenario, all of the jobs are known and present when the analysis begins, thus the 
question of the processing order is simplified. In a dynamic scenario, jobs arrive at 
intervals throughout the analysis period. Arrivals may be in set intervals or random and 
based on a probability distribution. In the dynamic case, the job shop problem takes on 
the characteristics of a queuing model. More randomness can be encountered if the job 


duration is not deterministic. 


c. n Jobs on m Machines 


In its basic form, the job shop problem assumes that all jobs, 1, arriving at 
the shop will be processed by all machines, m. The flow pattern of jobs can be dependent 
on precedence relationships, machine availability, processing times, and a host of other 
considerations. In the multiple machine case, each job may have a different duration for 


each machine. 


A special case of the multiple machine shop is one in which some or all of 
the machines are interchangeable. In that case, any job can be processed by any machine 
of its type and jobs do not need to be processed more than once by identical machines. In 
that situation, minimizing idle time on the machines, called line balancing, is an 


important consideration. 


28 


d. Sequencing Rules 


At the heart of any job shop problem is the selection of sequencing rules. 


Nahmias (2009) identifies the following commonly used sequencing rules: 


(1) First-come, first-served. Jobs are processed in the order they arrive. 

(2) Shortest processing time. The shortest duration jobs are performed first. 

(3) Earliest due date (EDD). Jobs with the nearest due dates are performed first. 
(4) Critical ratio (CR). A critical ratio is calculated for each job equal to the 
processing time divided by the remaining time until the due date as shown in the 
equation below. Jobs with the highest CR are performed first. 


= Processing time 
Due date - Current time 


e. Performance Metrics 


The measure of effectiveness used for a job shop solution can vary 
depending on its goals. Some metrics in common use are: 

(1) Flow time and mean flow time. Flow time is the total time to 
complete a given job from its entry into the shop to its exit. Mean flow time is the 
average of the flow times for all jobs. 

(2) Makespan. Measures the total time to complete all jobs. 

(3) Tardiness. Calculated as the difference between the completion 
time and the due date. A positive number indicates the job has been completed after the 


due date. 


f Job Shop Applied to the EVA Planning Problem 


Stripped down to its simplest form, the EVA planning process accepts 
tasks as inputs and produces as its output the most efficient sequence to accomplish those 
tasks. Next, we point out some significant differences between job shop problems and 


EVA planning. 
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The EVA planning problem, conceived as a job shop, is formatted as 
having static job arrival and two machines (crew members). Since, for the most part, any 
task can be assigned to either crew member, these play the roles of interchangeable 
machines performing parallel processing. This means the problem can be viewed as two 
separate single-machine job shops, albeit still subject to line balancing considerations. 
The situation is static because all tasks are identified up-front and so a time dependent 
arrival pattern and the resulting queue are not a factor. The result of these characteristics 
is that for the EVA problem, the focus shifts from the flow of tasks into and through the 


shop to the task allocation of the machines. 


Another change in focus from the job shop problem is that, in EVA 
planning, tasks are defined by their priority and duration rather than by a due date. As 
task selection and assignment are both variables that work in concert with sequencing, 
our problem differs from a classical job shop in that ours does not force all tasks to be 
processed. One immediate impact of these subtle differences is that the constraints on the 
problem are not related to task due dates but rather to available machine time. The 
standard job shop time-to-completion based performance metrics of makespan, tardiness, 
and flow time become meaningless for a single EVA. Task due date and the time-based 
performance measures could be applied to a system designing a series of many EVAs, 


but the primary focus of this thesis is for single EVA planning. 


The job shop problem nonetheless provides a basic framework for the 
single EVA scheduling problem. In particular, we intend to adapt the concept of 
sequencing rules to EVA planning. First, we must understand the subtle nature of the 
planning goals, two of which can be stated as (1) maximizing total task priority, and (2) 
maximizing priority per unit time during the EVA. The subtlety of the second goal is that, 
although an EVA is an activity of known duration, the task priority per unit time should 
be applied as a running value throughout the EVA, not just at its completion. This has 
great importance because of the possibility of early EVA termination or delays in tasks 
early in the timeline which may force tasks nearer to the end to be skipped. Both of these 


situations are outside the planner's control and result from unexpected events or 
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problems. Current planning heuristics mitigate these risks by scheduling high priority 
tasks as early as possible while maintaining overall efficiency. Any credible planning tool 


must address these considerations. 


The above discussion suggests the EDD sequencing rule is a valuable 
concept when applied to EVA task scheduling. Task priority replaces due date to create a 
new sequencing rule based on EDD. We refer to this as "highest priority first" (HPF). 
HPF sequencing would result in scheduling tasks in descending priority order, which 
serves the purpose of rewarding the scheduling of higher priority items earlier in the 
EVA. HPF cannot be the final word on task sequencing, however, because it does not 
account for task duration (or the many other limiting constraints). It is clear that to ensure 
the best outcome, task duration must be accounted for in concert with priority. To help 
address this, we can borrow again from the job shop problem. Adapting the concept of 
the critical ratio to define a priority ratio (PR), we can bring task duration and available 
time into the fold. The PR should look at the EVA as a whole to divide the sum of all task 


priority values by the total available time (in terms of PET): 
_ Total Task Priority 
Total Available PET 
A combination of HPF and PR can be used to create an EVA which has 


the highest overall priority value, but also the highest priority per unit time throughout 


the EVA. 


5. Summary 


The EVA planning problem is clearly a hybrid of many common problems in 
combinatorial optimization and the operations research literature. While no one model 
approach addresses all of the requirements and goals of the EVA problem, aspects of 
each of them can be applied to assemble a combined model which addresses the three 
sub-problems of task selection, crew assignment, and task sequencing. Sections C, D, and 


E outline those needs and develop the EPM. 
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B. OTHER EVA PLANNING IMPROVEMENT EFFORTS 


The EVA planning process has long been understood to be very time consuming 
for the planning experts. Attempts have been made to address this by applying advanced 


automation techniques to timeline generation. 


1. Prototype Knowledge-based EVA Planning System 


Notable among attempts to optimize the EVA planning process is a previous 
master's thesis by Bleisath (1995), then a member of the EVA planning group. That work 
developed an automated knowledge-based tool to create EVA timelines. The 
development focused on the scheduling of tasks and the ease of use of the resulting tool 
for the planners. It represents an EVA as a group of tasks that must be ordered optimally 
without addressing the question of task selection. Thus, it classifies the problem as a 


general job shop problem and utilizes heuristic search to approximate its solution. 


Two major factors drove the direction of that research: (1) the approach had to be 
practicable using computer power that was severely limited compared to the systems in 
common use today, and (2) it was undertaken at a time before any ISS EVAs had been 
planned or executed, and so did not have the full benefit of experience that we presently 


have at our disposal. 


Due to the limited computer resources available, formal mathematical 
programming was not considered a viable option, and the number of tasks that could be 
scheduled per EVA was relatively limited. As a result, the tool provides a somewhat 
limited, high-level output for EVA task sequencing (although it produces full timelines 
and includes an impressive amount of detail such as calculation of crew movement 


speeds in various configurations). 


The model has a limited set of input data and constraints which includes: 


e Task priorities 

e Precedence relationships 

e Concurrence relationships (e.g., tandem tasks) 

e Manual task placement (e.g., planners have the ability to override portions 


of its output manually) 
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e Assignment of specific tasks to specific crewmembers 
The tool developed by Bleisath produces impressive results but has not been in 
use by EVA planners due primarily to its omission of many nuanced constraints which 


have evolved throughout the operational history of EVA on ISS. 


Advances in computer power opens the option of utilizing formal mathematical 
programming. In addition, the wealth of operational knowledge from 15 years of ISS 
EVAs has allowed us to understand what data is easily available and how major tasks 
may be split into many subtasks. We can include notably more detail and realism in our 


model as a result of these advantages. 


2. Artificial Intelligence Based Planning Automation 


A more recent, and continuing effort, performed by TRACLabs, Inc. with NASA 
funding, investigates the automation of spaceflight planning from a wider perspective. 
This work is focused on automating planning for all disciplines in human spaceflight, 
including EVA. Bonasso, Boddy, & Kortenkamp (2009) utilize an EVA-centric scenario 
to serve as a test case and example of their efforts in automated mission planning. Their 
work focuses on integrating NASA's in-development procedure representation language 


with artificial intelligence (AI) based planning tools. 


A fascinating aspect of this research is that it delves to a much lower level of 
detail than we intend to do with EPM, but in the process are much closer to possible 
solutions to the sub-problem of task sub-division. Their starting point of using existing 
procedures to develop inputs for AI planners naturally leads to a focus on four things: (1) 
decomposition of tasks into smaller parts, called hierarchical task nets, (2) assessing the 
resources associated with tasks, (3) thinking of tasks in terms of beginning states and 
ending states, and (4) understanding the interaction between actors and _ the 
interoperability of systems involved with the execution of tasks. Figure 7 represents a 
typical hierarchical task net developed by TRACLabs to decompose an EVA task called 
Remove CETA Light. The figure highlights the differences in the planning level of EPM, 
which considers Remove CETA Light as a single task needing no further decomposition, 


to the high level of task dissection performed for the AI planner. 
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Figure 7. _ Hierarchical task net (from Bonasso, Boddy, & Kortenkamp (2009)) 


The ability to fully model the interoperability of systems and the interaction of 
different actors in the performance of a task is well beyond the scope of the EPM, as is 
the focus on resources. In many task decompositions, the leaves, or lowest level of the 
network may all be performed by different actors (flight controllers, EVA crew members, 
crew members inside the ISS, etc.). Further, the tracking of resources is very meticulous, 
including any and all countable resources that can be used, consumed, or produced by a 
given task. For the EPM, we understand time and tools or equipment are important 
resources (although tools are left to future refinements of the model), but do not attempt 
to track or constrain EMU oxygen levels or carbon dioxide removal system consumption 


as the automation tool does. 


In the actual planning of EVA activities at the high level, the EPM employs 
optimization to select, assign, and arrange tasks whereas the planning system currently 
utilized by TRACLabs is driven wholly by heuristics with the human expert planner left 
to do any optimization. It is exactly this optimization that the EPM is intended to aid and 
thus there is possible synergy between the two efforts. One possible collaboration area is 


in sharing of the task database and resource database for future versions of EPM. 


C. MODEL REQUIREMENTS 


This section outlines the basic requirements of the EVA planning model including 
time and crew limitations, first order constraints, and outputs. Any requirements which 
are omitted or simplified will be discussed. The subsequent sections describe the details 


of the included requirements and show how they are being addressed. 


1. Basic Summary Timeline Development 


The EPM must accept input data from the user in the form of tasks and task 
attributes and output a summary timeline for a single EVA that can serve as a basis for 
evaluation by an expert planner. Creation of this timeline necessitates that the model 
selects tasks from a provided list and orders them in such a way as to maximize the 
priority value of the EVA. The model should then allow iteration to portions of the plan 
that do not meet customer or operational needs while holding the satisfactory part of the 


plan steady. 


EPM output can be the basis for further evaluation, development, and training, as 
in Figure 1, or as supporting material for negotiations with the program customer 


regarding task priorities and/or expectations of task allocation to specific EVAs. 


2. Task-Specific Conditions 


The model should account for the conditions and special circumstances identified 
in Section I.B when generating EVA timelines. Subdivision of tasks and task synergy are 
not part of the model requirements at this time. The insight and intuition necessary to 
perform these functions is beyond the scope of a first-generation planning model. 
Certainly, though, the model can still aid a planner in subdividing tasks by providing 
optimal timelines throughout the process and making the impacts of any subdivisions 


more obvious. 
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os Crew-Specific Adjustments 


The model should account for differing crew skill levels and the desire to assign a 
specific crewmember to a specific task for any number of reasons (e.g., higher training or 


experience level). 


4, Omissions 


Although identified as important aspects of EVA planning, the EPM does not 
currently address tool constraints or subdivision of tasks (and as a result, break-out 
times). Neither is task synergy incorporated in the model. These capabilities involve 
significant complication well beyond the other rules and constraints handled currently by 


the EPM. 
D. INPUTS 


The EPM accepts inputs in the form of text files produced using templates in 
Microsoft Excel. These files and the data they contain are described below. All sample 
files shown are from the LEE R&R contingency EVA, the summary timeline for which is 


shown in Figure 2. 


1. Task Data 


For each task, the model requires the following data: 


e Task name 
e Task priority (in "value" units, where higher values indicate higher 
priority) 


e Task duration if performed by EV1 or EV2 (in minutes) 
e Task bingo time, if required (in minutes) 
Each task also has a set of binary flags (1 if true and 0 if false) associated with it 


to indicate whether or not: 


e Task is mandatory 

e Task requires both crewmembers (tandem) 

e Task carries the risk of toxic fluid contamination on the EMU suit 
e Task has a limited set of legal time windows 
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e Task has a bingo time 
e Task is the final airlock ingress 


Table 1 is the input template for the data described above. 








g la |e 

Eales es oa eae eres lee 

3° = = = e & x n A oo 

Ea cau eee a eee Sa ae 

PVGF_Release_from_EP 5 5 6 0 0 0 0 0 0 0 
P1_Worksite_Setup 5 30 33 0 0 0 0 0 0 0 
Remove_CLA 5 10 11 0 0 0 0 0 0 0 
Translate_Failed_LEE_to ELC1 5 30 30 0 1 0 0 0 0 0 
Spare_LEE Prep 5 45 50 0 0 0 0 0 0 0 
Stow_Failed_LEE_on_Temp_Stow_Ring 5 35 35 0 1 0 0 0 0 0 
Retireve_Spare_Lee 5 40 40 0 1 0 0 0 0 0 
Translate_Spare_LEE_to_P1 Worksite 5 30 30 0 1 0 0 0 0 0 
Install_CLA 5 10 11 0 0 0 0 0 0 0 
Install_LEE 5 30 30 0 1 0 0 0 1 270 
LEE_FSE_Cleanup 5 9 10 0 0 0 0 0 0 0 
Remove_LEE 5 40 40 0 1 0 0 0 0 0 
Cleanup_ Ingress 5 30 30 1 1 1 0 0 0 0 
Egress Setup 5 15 15 1 1 0 0 1 0 0 


Table 1. | Task input data template 


Tasks that have time windows have additional data input requirements. In 
addition to flagging them in the above-mentioned template, the allowable time windows 
must be specified separately. For each such task, the following data are required 


(template shown in Table 2). 


e Window, task joint identifier 

e Start time of each window (in minutes, PET) 

e End time of each window (in minutes, PET) 

tmin tmax 

wl Egress Setup 0 30 
wl Sample_Task 30 65 
w2 Sample_Task 90 100 
w3 Sample_Task 210 220 


Table 2. Task-time window input data template 


ay 


2. Precedence Relationships 


Tasks with precedence relationships are specified in a separate input file via a 


predecessor-successor data structure. Tasks can be paired or chained with any number of 


other tasks to create unique and complicated relationships. Table 3 shows a typical 


precedence relationship input in the template. 


Predecessor 


P1_ Worksite _Setup 

Remove_LEE 

Remove_CLA 

Translate Failed LEE to ELC1 
Spare_LEE Prep 
Translate_Failed_ LEE to ELC1 
Retrieve_Spare_Lee 

Remove_CLA 

Remove_LEE 
Translate_Spare_LEE_to_P1 Worksite 
Install CLA 

Translate_Spare_LEE_to_P1 Worksite 
Retrieve_Spare_Lee 
Stow_Failed_LEE_on_Temp_Stow_Ring 
Translate_Spare_LEE_to_P1 Worksite 
Remove_CLA 

P1_ Worksite Setup 
PVGF_Release_from_EP 
Stow_Failed_LEE_on_Temp_Stow_Ring 


Table 3. 


3. Task Location Data 


Successor 


Remove_CLA 

Translate_Failed LEE to ELC1 
Translate_Failed LEE to ELC1 
Stow_Failed_LEE_on_Temp_Stow_Ring 
Retrieve Spare _Lee 

Retrieve Spare Lee 
Translate_Spare_LEE to _P1 Worksite 
Install CLA 


Install CLA 
Install CLA 
Install LEE 
Install LEE 


LEE_FSE_Cleanup 
LEE _FSE_Cleanup 
LEE _FSE_Cleanup 
Remove_LEE 
Remove_LEE 
Remove_LEE 
Retrieve Spare Lee 


Task precedence relationship input data template 


All tasks have associated worksites. Since some tasks can include a movement of 


the crewmember from one worksite to another, the model requires inputs for both the 


starting and ending location of each task (see Table 4). For convenience in our 


implementation, these two locations are entered in separate files. 
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Task 


PVGF_ Release _from_EP 

P1 Worksite Setup 

Remove_CLA 

Translate Failed LEE to ELC1 
Spare_LEE Prep 
Stow_Failed_LEE_on_Temp_Stow_Ring 
Retrieve _Spare_Lee 

Translate _Spare_LEE_to_P1 Worksite 
Install_ CLA 

Install_LEE 

LEE_FSE Cleanup 

Remove_LEE 

Cleanup_ Ingress 

Egress Setup 


Initial Location 


HTV 
Columbus_WIF3 
P1_ Worksite 
P1 Worksite 
ELC1 

ELC1 

ELC1 

ELC1 

P1 Worksite 
P1_ Worksite 
ELC1 

P1 Worksite 
Airlock 
Airlock 


Final Location 


HTV 

P1_ Worksite 
P1_ Worksite 
ELC1 

ELC1 

ELC1 

ELC1 

P1 Worksite 
P1 Worksite 
P1_ Worksite 
ELC1 

P1 Worksite 
Airlock 
Airlock 


Table 4. Task location input data template 


4. Translation Times 


In order to convert the task location information into data useful for the EPM, the 
translation time between all worksite locations associated with a given set of tasks must 
be provided. The values are given in minutes and entered in a matrix format as seen in 
Table 5. Note that the matrix allows for different translation times depending on the 


direction traversed. 


To ; 
Airlock HTV ELC1 P1 Wrkst Col_WIF3 
From -_ Z 
Airlock 0 10 15 13 8 
HTV 10 0 20 13 2 
ELC1 15 20 0 13 20 
P1_Wrkst 13 13 13 0 13 
Col_WIF3 8 2 20 13 0 
Table 5. Translation time input data matrix 
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5. Model Constants 


The model utilizes several constants which can be adjusted if needed to change 
the parameters of certain planning constraints or to weight the relative prioritization of 
model objectives. These constants and their default values are: 

® Priority Rank Weight [unitless], default value = 0.1 

e Rank Start Time Weight [value/min], default value = 0.0001 

e Total EVA length [minutes], default value = 390 minutes 


e Latest bake-out start time [minutes], default value = 240 minutes 
E. FORMULATION 


This section introduces the mathematical formulation of the EPM as a linear 
mixed-integer program (MIP) that can be used to create or modify EVA summary 


timelines. 


1. Mathematical Model 


Sets: 

J, set of tasks, where j is the airlock ingress task 

K, set of ranks (task sequencing order), where K = loa } 

C. set of crew members, where C = {EV1, EV2} 

I, subset of J that requires two crew members. Note: jer 

QO, subset of pairs of tasks, (j, j')}€Q<JxJ,where j precedes j' 

M, subset of J comprised of mandatory tasks that must be completed 
regardless of priority. Note: j ¢ M 

HA, subset of J which carry the risk of toxic fluid contamination on 
EMU suit 

Le subset of J which must be scheduled in time constrained windows, 


defined in set W 
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Data [units]: 


a: 


ae 


Pi 


B;. 


min 
wij ? 


t 


max 
wij ? 


t 


set of time windows defining allowable periods to perform tasks 


identified in set L 


subset of L which cannot start at time zero (i.e., do not have a time 


window that includes time 0). 


subset of J which has a bingo time constraint (i.e., task must be 
scheduled such that it will be completed by a certain time or it 


should not be attempted) 


duration of task j for crewmember c (for tandem tasks it should 


be made the same for both crew irrespective of their skills) [min] 


priority value of task 7 [value] 


objective function weighting coefficient for task priority [unitless] 


objective function weighting coefficient for task start time 


[value/min] 


translation time between tasks j and j' (based on the final and 
initial locations for both tasks, respectively) [min] 


latest airlock ingress completion time (this is the maximum 


allowable EVA duration) [min] 
latest bake-out start time [min] 


latest start time for task j € B [min] 
first allowable start time in window w for task j ¢ L [min] 


latest allowable end time in window w for task j ¢ L [min] 


Decision Variables [units ]: 


jk? 


1 if task 7 is selected in rank k for crewmember c, 0 otherwise 


4] 


V ieee 2 


start time for rank k of crewmember c [min] 
start time for task j for crewmember c [min] 


lif task j' follows task j in adjacent ranks, k and k+1 for 
crewmember c, 0 otherwise 
1if task 7 is scheduled in window w for crewmember c, 0 


otherwise 


Objective Function: 


Subject To: 


P 
maximize » (1S rae > O'S, 


Jed .keEK ,ceC keK,ceC 


Yi.c€{Ol}, VieJ.keK,ceCc 


Ris E{0,1}, VweW,jeJ,ceC 
E{O,1t, Vj, j'eJ,keK,ceC 


dd Kc 


dp¢20, VREK Cet 
U2 0; VWieJ,cec 





O ge Spe 2A ys VWieJ,keEK,ceC 
Ug Sy ohn rd gs) VWieJ,keEK,ceC 
USA) Y, VieJ,ceC 


dike ? 
kek 





VY cc2 Yee Wee K,cec 


Jed jet 
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(1) 


(2) 


(3) 


(4) 


(5) 


U,.+d,<A, VeoeC (6) 


U.5U. 3 WeT,cec (7) 


», Vigcsly VET OM 


keK,ceC (8) 
» Gags? s Wren \M 
keK,ceC 
De Viaa = Vea» WET (9) 
keK keK 

U,,=U,., VjeT (10) 


>, Yae=l, WieM\T 


keK,ceC (1) 
Y Vg? NEM OF 
keK,ceC 
> Lely VRek eee (12) 
Jed 
Spare 2 Stet >, 4;e¥ igor » Xi iViice > Vk eK,ceC 
jet pesljej' 
Vides SVite 9 Vij €J,keEK,ceClj#i' (13) 
Vie SV iste > Vij €J,kKeEK,cEeCljFy' 
Vieeg pel eye tt eae ls Vij €J,kKeEK,cEeCljFy' 
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> Yiree S De jk ? 


keK,ceC keK,ceC 
2 a Dp 4 ike? 
keK,ceC keK,ceC 
by Vine Sz pe Vine > 
keK,ceC keK,ceC 


De® WG ie Ape DV ine) 2AI~ YL Vachs 


ceC ceC keK 

Se 7 sede 
2 2 

SU .2 DU +4; DY 
2a ceC keK 

DY ie? 

ceC 2 eee keK 


Y, 


ike 


SLU. +4,. DY je) 221 — es ike)? 


ViJ EQIZ, 7 €ETV i,j ¢T 


Wij €QljeT,j eT 


Vi, i'e€OljeT, jeT 


Vi, J €Q\j,j eT 


keK ,ceC 
Dea a aoe Vie Oly eT 
keK,ceC 
ike) 2A(2 = Dap nc Wij €QIjeT, j'eT 
keK,ceC 


ViJ'€Ql|jeT,j'¢T 


keK ,ceC 
UO; S009.  VieeH,cee 
U,.S8,-4, , WeEB,ceC 


cali VieL,ceC 


wie? 


VjeL,ceCc 


= Ue 


J,€ 


VieJ’.kEK,cEeC 


2. Model Description 


(14) 


(15) 


(16) 


(17) 


(18) 


Equation (1) is the objective function of the EPM. The objective is to maximize 


the total priority value of tasks selected, and to maximize the priority per unit time 


throughout the EVA. Indirectly, by pushing tasks earlier when possible, the latter should 


44 


minimize early idle time during the EVA (excluding the idle time for an EV waiting for 
the other crewmember before airlock ingress). The objective finction is broken into two 


distinct terms to accomplish these goals. 


Examination of the first term reveals that it is a variation of the knapsack 
objective formulation combined with the HPF and PR concepts derived from the job shop 


problem as discussed in Section II.A.4. Tasks are selected, assigned to a crewmember, 


and placed into a series of sequential ranks, k € {1, 23.16 } . Each of the selected task's 


priority values contribute to the total objective value, but those values are decreased by a 
factor that is inversely proportional to their assigned rank number. This results in a 
penalty for placing tasks of equal priority into later ranks. It can be easily proven that, all 


else being equal, a task with higher priority value will be preferred for a lower rank after 


adjusting priorities with the (1+°’£) factor. 


The second term in the objective function serves the purpose of imposing a 
penalty on unnecessary gaps between rank start times (and thus between task 
assignments). This has three effects: (1) to push tasks as early as possible in the EVA 
(helping to minimize idle time), (2) to minimize the duration of an EVA that has fewer 
than the maximum number of tasks, and (3) to enforce a job shop style line balancing 


between the two crew members. 


The two constants, @’ and @’, are values which establish the relative importance 


of the task selection by priority and early scheduling, respectively. 


The constraint equations that follow are organized into multiple groups, each with 
a single associated equation number. In cases where the group as a whole is referenced, 
we use the given equation number for the group (x), whereas the y-th explicit expression 


within that group will be referenced in the format (x.y). 


Equation (2) defines the three types of binary decision variables and Equation (3) 
defines the rank and task start time variables as being non-negative. Equation (4) 
establishes the relationship between rank start times and task start times. The start time 


for any task is set equal to the start time of the rank for which it is slotted. If the task is 
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not scheduled, the associated start time is unconstrained. The constant 2/Ais used as it 


represents an upper bound to all allowable values of U,.. Additionally, all task start 


times are constrained to occur before latest airlock ingress time. Equation (5) stipulates 
that no empty ranks can exist prior to a rank which is assigned a task. This is required to 
ensure that translation times are properly accounted for later (in particular, in Equation 
(13)). Equation (6) forces the airlock ingress task (identified as 7 which is always the 
final task of an EVA, to be completed no later than a pre-specified maximum EVA 
duration of 2, while Equation (7) ensures that the airlock ingress is the final scheduled 


task by eliminating any task start times after it. 


Equation (8) prevents the repeated selection of tasks for both solo and tandem 
tasks. Equations (9) and (10) provide tandem task constraints such that a tandem task 
must be scheduled for both crewmembers or not at all, and that, if scheduled, start time of 
tandem tasks must be the same for both crewmembers. Mandatory task assignment is 
handled by Equation (11), forcing all tasks flagged as mandatory to be selected. It 
includes a coverage of solo and tandem mandatory tasks. Equation (12) prevents any 
conflicts associated with oversubscribing ranks. Each crewmember can have no more 


than one task assigned to each rank. 


The group of constraints given in Equation (13) are related to crew movement 
between tasks. Translation time between task worksites is accounted for by exploiting the 
fact that Equation (5) disallows skipped ranks. Thus we know that tasks slotted into ranks 
k and k+1 for a given crewmember must be adjacent in time. The index j' is 
introduced to allow us to represent two independent tasks from set J in the same 


equation. Binary variable V, ,.,. is introduced to allow a linear expression indicating that 


a transition between two specific tasks, j and j' occurs. Equations (13.2) - (13.4) ensure 


that V, 


j\kc takes a value of one if and only if task j is scheduled in rank k and task j' 


is scheduled in rank k+1 for crew member c. Once the translation order is established, 
Equation (13.1) constrains the start time of the next rank to include the previous rank's 


task duration and the appropriate translation time, x, ,.. 
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Equation block (14) handles task precedence for the general case and several 
special cases. Firstly, Equations (14.1) through (14.3) ensure that a successor task, 
indicated by j', cannot be selected if the predecessor task has not been selected. The 
remaining equations constrain the start time of successor tasks to be after the completion 


time of any predecessors. If j is never completed, then U.. is unconstrained, thus j' 


will never be scheduled if j is not scheduled, but j may be scheduled even if j' is not. 


The multiple versions of these expressions in Equation block (14) are required to handle 


all permutations of tandem and solo tasks among tasks with precedence relationships. 


Equation (15) handles tasks flagged as having a possibility of EMU 
contamination with toxic materials and forces them to be completed prior to the latest 
bake-out time, 6 . Note that bake-out requires a period of sun exposure for the EMU suit 
and is therefore dependent on sunrise and sunset times. Since there is a sunrise and sunset 
every 45 minutes at the orbital velocity of the ISS and many factors (including some 
unplanned factors) contribute to a variability of the crew's workday in relation to orbital 
day and night, the phasing between sunlight conditions and PET cannot usually be known 
until relatively close to the time of EVA execution. Fully optimizing the bake-out 
constraint through the setting of 6 is difficult during the planning phase, which can 
occur months prior to the actual EVA. A conservative approach to establishing the bake- 
out start time would be to simply set 6 at a level that guarantees a sufficient bake-out 


regardless of orbital sunrise and sunset times. This worst case would prompt the user to 





set 0=A—d-.—d,;..—x,;—45, that is the EVA end time minus the combined duration 


of airlock ingress, the bake-out activity, the translation time between the hazardous task 


and the airlock, and a 45 minute pad for worst-case day/night phasing. 


Equation (16) constrains the start time of tasks which have been flagged as having 
a bingo time. These are tasks which must be completely finished to avoid an undesirable 
configuration of the vehicle or have some other negative consequence if left incomplete. 


Each task in set B can have its own unique bingo time, so they are handled individually. 


Equations (17) and (18) handle constraints for tasks with specific allowable task 


windows. Task windows are defined by the user with a beginning time and end time. For 
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a task flagged as having a time window, there is no limit to the number of allowable 
windows it can have. The model requires that the entire duration of the task fits into 


whichever window is selected. We introduce the binary decision variable, R to 


wfc? 
denote selection of a specific window for a given task. Equation (17.1) constrains the 
start time of the task to be such that the entire task will fit in the defined window, while 
Equation (17.2) ensures that a window is selected if and only if the associated task has 
been selected. Equation (18) handles the special case of tasks with time windows that do 
not include PET = 0 minutes. Specifically, it disallows the start time of the task to be 0 


minutes if the task is selected. 


3. Implementation 


The EPM is implemented in the General Algebraic Modeling System (GAMS) 
(Brooke et al., 2012) and all EPM runs described in this research are solved using 
CPLEX (GAMS/CPLEX, 2012) as a solving engine, on a desktop computer equipped 
with an Intel Core 17 CPU with eight processor cores running at 2.67 GHz and 6 GB of 
RAM. 


A typical instance of EPM, such as black-box test case 1d, described in detail in 
Chapter IV, has approximately 19,000 constraints and 6,800 binary variables. Solve time 


for an optimal solution (at 0% optimality gap) ranges between 2 minutes and 18 hours. 
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HI. MODEL TESTING AND VERIFICATION 


This chapter describes the testing approach used to verify the EPM and presents 
model results. We employ verification techniques to provide thorough vetting of the 
model's correctness. Note that while verification is crucial for the EPM, full validation is 
not addressed here. This stems from the fact that the EPM has been built specifically to 
address the requirements in Chapter II, where any planning requirements that are deemed 
too complicated for the initial development of the model have been relaxed or omitted. 
Accordingly the model testing presented in this work seeks to demonstrate EPM at the 
proof-of-concept level, striking a balance between actual problem requirements and 


capabilities for practical use in EVA plan development. 
A. METHODOLOGY 


A full quantitative evaluation of the quality of the EPM in the traditional sense is 
not possible at this time. This is a result of several factors: (1) there is no established 
metric available to compare the quality of one EVA plan to another, (2) EVA planning 
relies heavily on heuristic approaches, and (3) decisions made in finalized EVA plans are 
not typically documented in a form that allows us to know which alternatives were 


considered and why they were rejected. 


The manual nature of EVA planning is the biggest barrier to the creation of an 
autonomous EVA planning tool. It is also the most problematic aspect of approaching the 
question of measuring the output quality of even our basic EPM. Of course, many of the 
decisions involved in planning an EVA relate to which tasks will be included and the 
order in which they will be scheduled, but many more are related to the sub-division of 
tasks. Tasks may be sub-divided for myriad reasons, including, but not limited to: 
optimization of task locations to best utilize tether points, handholds, and permanent or 
moveable work fixtures, the tools required, and the body positioning or approach path for 


the crew. These complexities have been omitted from the EPM in order to simplify it 
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enough to make its development practical within this study. While this simplification is 
necessary to limit the scope of model development to a feasible size, it also rules out a 


strictly quantitative testing standard. 


Given the lack of an ultimate quality metric, we focus our testing strategy on 
verifying that the implemented features execute as expected. The question of verification 
is by no means a simple one because the optimization model includes many nested 
logical conditions to account for constraints. Very few of these constraints are mutually 
exclusive, making testing a significant challenge. To develop a credible verification 
testing plan that remains manageable, we look to the field of software engineering. In this 
way, we view the EPM MIP formulation as a series of logical “if-then” statements as in a 
standard computer program. Each constraint (or group of constraints with a particular 
joint function) becomes a branch in the logic tree of the program that (when combined 


with all the others) comprises the EPM. 


One potential approach to test such a program is exhaustive testing, wherein we 
test every possible logical combination in the model to ensure, ostensibly, that no errors 
remain undetected. Even in a very simple program with a small number of if-then 
constructs, exhaustive testing is an exceedingly daunting proposition and that for large or 
complex software systems it is effectively impossible. Exhaustive testing is a form of 
"white-box" testing which "is predicated on close examination of procedural detail. 
Logical paths through the software and collaborations between components are tested by 
exercising specific sets of conditions" (Pressman, 2010, p. 484). White-box testing 
provides exactly what we need to verify a model like the EPM and thus forms an 


important part of our testing strategy. 


Our methodology is based on these guidelines suggested by Davis (1995): (1) 
tests should be planned before testing begins, (2) testing should start "in the small" and 
progress toward "in the large," (3) the Pareto principle applies to software testing (80% of 
errors will likely be traced to 20% of the program components), and (4) exhaustive 
testing is not possible (as cited in Pressman, 2010). EPM testing is accomplished in three 
phases which progress in scope from single elements to the entire model. We begin with 


unit testing of the individual components, move on to white-box testing of logical 
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sequences or processes, then to “black-box” testing. Black-box testing is not concerned 
with the internal workings of a software element, but rather focuses on its ability to 
produce expected outputs from known inputs. Black-box testing will provide the ultimate 
measure of the acceptability of the model as a whole and provide insight as to the 


feasibility of further development of the EPM into an operational tool. 
B. UNIT TESTING 


Throughout the development of the EPM, unit testing was constantly performed 
to verify functionality of individual components. The purpose of unit testing is to 
examine the basic building blocks of the model. The goal is to create test cases that 
exercise the smallest components while also reducing interaction with other segments as 


much as possible. See Tables 6 and 7 for documentation of the unit tests and their results. 
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Unit Test 


Test Configuration 











Expected Output Test Result 
Number 
Test Goal Test Setup 
Input set of solo tasks with 
Verify solo tasks can be no special constraints. Total 
Y pe ; All tasks scheduled Pass 
scheduled task time < available PET. All 
translation times equal. 
Verify no uneccesary idle No idle time is included between any 
1 . s Same as case 0 Pass 
time in output tasks 
F : . Same as case 0. Translation . . 
Verify translation times are |_. ; Translation times are correct and 
2 times between all locations Pass 
accounted for ‘ accounted for 
are unique. 
F Task assignment is split between crew 
Verify crew member . 
3 . . i, Same as case 0 members such that they have relatively Pass 
assigment is optimized (a) . : 
equal total task+translation durations 
Same as case 0 but with all 
tasks having equal priority. 
F All tasks have a duration of . ; . 
Verify crew member ; : : All tasks with duration difference 
: assigment is optimized (b) ASIMIREIES Hi-csSiEneG se assigned to EV1 Rass 
i i imiz i 
g p EV1, half of the tasks have a 8 
duration of 30 minutes if 
assigned to EV2. 
Same as case 4 but with all . . . 
; . . Task assignment is split between crew 
Verify crew member tasks having a duration of 10 : 
5 : ; oa : members such that they have relatively Pass 
assigment is optimized (c) minutes for EV1 and 30 . : 
. equal total task+translation durations 
minutes for EV2. 
Same as case 0 but with at 
Verify tandem tasks can be : All tandem tasks scheduled for both 
6 least 1 tandem task(s) in Pass 


scheduled 





input set. 





crew members at the same PET 








Table 6. 
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Unit test configurations and results (unit test numbers 0-6) 








Test Configuration 











Unit Test 
Expected Output Test Result 
Number 
Test Goal Test Setup 
Input set of solo tasks of 
‘ Verify EVA PETis limited to [equal duration, unique EVA duration is limited to no more than sees 
specified duration priority, and no special the specified limit 
constraints. Total task time > 
ae a Tasks included in EVA to fill all available 
Verify highest priority tasks : 
calacted Same as case 7. PET, excess tasks omitted based on Pass 
priority (lowest are omitted) 
Same as case 7 but with the 
Verify mandatory tasks are Ate Mandatory task scheduled at the 
lowest priority task flagged : ri Pass 
selected expense of a higher priority task 
as mandatory. 
Same as case 9 but with the 
Verify bingo times are . Mandatory task is scheduled such that 
10 mandatory task assigned a ee ; . . Pass 
adhered to . : completion is prior to the bingo time 
bingo time. 
Same as case 9 but with the 
Verify bake-out times are Mandatory task is scheduled such that 
11 mandatory task flagged as OL was ; Pass 
adhered to toute completion is prior to the bake-out time 
ic. 
ae . Same as case 9but with the |Mandatory task is scheduled such that 
Verify time windows are : csellid ttn cnet’ ceive. cra 
12 mandatory task given a completion is within the specified time Pass 
adhered to betes ; . 
specific time window. window 
5 Basic task predence is Same as case Obut one task /|Successor task is scheduled after — 
adhered to is assigned a predecessor. associated predecessor is complete 
ea & : Same as case 2 but for test Translation times for test task properly 
Verify in-task translations : : Anaigs ; . , 
14 task, assign different initial |account for different starting and final Pass 


are accounted for 





and final locations. 





location 








Table 7. 


C. 


WHITE-BOX TESTING 


Unit test configurations and results (unit test numbers 7-14) 


As pointed out in the previous sub-section, ad hoc testing became an important 


part of the process in real-time. As new capabilities were added to the model, simple 


impromptu tests were performed to ensure the model performed acceptably. Although 


these tests were not formally organized or documented, they provided valuable insight 


about where errors may reside in the logic. Based on this experience, we are able to 


empirically confirm the application of the Pareto principle, specifically related to portions 


of the model related to precedence relationships. We also found that errors tended to lurk 


where constraints intersected, for example precedence relationships between solo and 


tandem tasks. 
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Exhaustive testing of even this part of the model, as pointed out, is nearly if not 
wholly impossible. The number of test cases needed to evaluate all possible combinations 
of constraints is astronomical. In fact, the number of test cases is unbounded since there 
is no limit to the number of tasks (and associated attributes) that can be fed into the 
model. As such, we utilize the concept of basis path testing for the EPM. Basis path 
testing is a form of limited white-box testing commonly used for software programs with 
large logical control structures. To perform this type of testing, we first conceptualize the 
EPM as a series subroutines comprised of if-then statements. We then create control flow 
graphs for the subroutines and determine all possible logical paths through the graphs. 
These paths are referred to as a basis set and by creating test cases for each basis set, we 
ensure that each logical path within the subroutine will be exercised at least once with the 
minimum number of test cases (Pressman, 2010). While it is certainly possible for errors 
to slip though this testing, the technique provides a very attractive return on investment in 
terms of testing efficiency. The number of test cases required to complete basis path 
testing is given by the cyclomatic complexity of the subroutine's control flow graph. 
Calculating the cyclomatic complexity, V(G), from the graph can be accomplished by 
simply counting the regions bounded by the edges and nodes in the graph (plus the region 
outside the graph) or by using one of the calculations below: 

V(G)=E-N+2 
V(G)=P+1 


In the first expression, E is the number of edges and N is the number of nodes 
in the flow graph. In the second expression, P is the number of predicate nodes. A 
predicate node is a node which contains a decision and thus has more than one edge 


exiting from it. 
Figure 8 shows the control flow graph for the precedence relationship portion of 
the EVM. All three methods above yield V(G) =13 and thus the basis set contains 13 


independent paths. This defines the number of test cases that must be run to test every 
part of the subroutine at least once. The flow graph is built from the perspective of a 


specific task, j, which is considered by the model for placement in a timeline. It shows 
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the multiple factors that play into scheduling a task with predecessors, including whether 
feasible start times (notated by the shorthand "U " in the graph) exist. This routine is used 
to establish if task 7 can be scheduled and to define when it can be scheduled. Assuming 
the task can be scheduled, there is no guarantee that it will be scheduled, the routine 
simply allows the rest of the optimization model to consider the task alongside all other 
candidates, while observing the timing limitations placed upon it by its precedence 


relationships. 

One notable exception from the flow graph is a check if task j is flagged as 
mandatory. This is omitted because the model will exit without a solution in the case of a 
mandatory task that is impossible to schedule for any reason. Since we know such an 


input configuration will cause the model to fail to complete, there is no need to include it 


in the graph. 
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Predecessor Completed? 
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Predecessor Tandem? 


No 
U allowable from Eqn. 14,x and 17? 


jhas Bingo? 








U allowable from Eqn. 14.x and 16? 












U allowable from Eqn. 14.x and 15? 
Unevaluated Predecessors Remain? 






Figure 8. | EPM precedence relationship control flow graph 
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Table 8 is the complete listing of all 13 path test cases comprising the basis set 


generated from the flow graph in Figure 8, their configurations, expected outputs, and 


results. The original test results (not shown) proved very useful as several errors in the 


model formulation and/or code were identified and corrected as a result of performing the 


test cases. Table 8 displays all tests passed after the errors were corrected. 





Test Configuration 





























Path Test 
= — Expected Output Test Result 
Number Characteristics of Characteristics of Test Task, 
Predecessor Task, j p ir 
ze n/a Task j; has no predecessors |Taskj7 scheduled Pass 
1 Not complete n/a Task j ; not scheduled Pass 
Sol ind bi 
2 Completed, Solo me fies Morne reed Task j; scheduled after jp Pass 
not toxic 
3 Two predecessor tasks, both |Solo, no window, no bingo, |Taskj7 scheduled after both a 
completed not toxic predecessors 
Solo, no window, no bingo, ; ; 
4 Completed, Tandem : Task j ; scheduled after jp Pass 
not toxic 
Tandem, no window, no . . 
5 Completed, Tandem : B Task j; scheduled after jp Pass 
bingo, not toxic 
Tandem, no window, no . . 
ze Completed, Solo : : Task j; scheduled after jp Pass 
bingo, not toxic 
Solo, infeasible window, no ; 
7 Completed, Tandem . : Task j ; not scheduled Pass 
bingo, not toxic 
Solo, feasible window, no Task j; scheduled after jp, in valid time 
8 Completed, Tandem 7 ‘ Pass 
bingo, not toxic window 
Tandem, no window, 
Completed, Solo infeasible bingo time, not Task j 7 not scheduled Pass 
toxic 
4g Caridlated: Sela Hater, ne mune Task j 7 scheduled after jp, before bingo pace 
feasible bingo time, not toxic|time 
Tandem, no window, 
11 Completed, Solo feasible bingo time, Task j 7 not scheduled Pass 
infeasible bake-out time 
Tandem, no window, 
' . : ; Task j; scheduled after jp, before bake- 
12 Completed, Solo feasible bingo time, feasible Pass 
? out and bingo times 
bake-out time 
Table 8 EVM precedence relationship basis set test configurations and results 
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D. BLACK-BOX TESTING 


Black-box testing of the EPM is envisioned as a large scale exercise of the model 
as a complete unit. The purpose is to verify that the model can successfully create an 
optimized EVA timeline given a complete set of input data (as opposed to function- 
specific testing). The results of this testing are qualitative and by no means 
comprehensive, but this testing is a straightforward approach to evaluating overall model 
capability. Five test cases are generated for this purpose. Table 10, found at the end of 
this section, compares some key statistics between heuristic and EPM-generated 
timelines. In this section, "heuristic" refers to a solution manually generated by the author 


(not an EVA planner expert) using reasonable criteria derived from interviewing experts. 


1. Black-box Case 1 Configuration 


This case is intended to show optimization of task selection and ordering that may 
be time consuming or counterintuitive to a planner using manual and/or heuristic 
methods. Figure 9 is a graphical representation of this case. Each circle represents a task 
with the size of the circles representing the task's relative priority. The combined duration 
of the input tasks is greater than the available EVA PET, forcing some tasks to be 
excluded from the plan. As shown, tasks are split into three worksites with arrows 
indicating the translation times between worksites. All tasks have the same priority value 
save for one high-priority (but not mandatory) task. Task 5 has a priority value that is 1.5 
times greater than each of the other tasks. The lower priority tasks are divided into two 
groups of co-located tasks. Worksites for both of these groups are close to each other and 
to the airlock, while the high-priority task is located far from all of them. All tasks are 
tandem and of the same duration. The green circles for Task 1 and Task 8 indicate they 
are mandatory, as these are the airlock egress and ingress tasks, respectively. The airlock 


egress task is constrained to occur first by the use of a time window. 
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Worksite B 
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Worksite A 


10 minutes 
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2 5 minutes Ae 


Worksite C 


25 minutes 





Figure 9. —_ Black-box test case 1 configuration 


The goals of this test case are to determine which tasks will be omitted from the 
timeline and how the model will sequence the tasks given the large time penalty for 
translating to and from worksite A to complete the high-priority Task 5. We will also 
compare the model result to a basic heuristic approach to the same inputs to examine the 


differences between the two results. 


2. Black-box Case 1 Results 


One heuristic approach to this test case might be to perform the highest priority 
task first, then move to worksite B, which has the largest concentration of tasks, perform 
as many of those as possible, then move to worksite C to perform tasks there if time 
allows before returning to the airlock. That approach results in the timeline shown at the 


top of Figure 10 and yields an objective score of 46.44 value units. 


The EPM output is substantially different. Its output timeline is shown at the 
middle of Figure 10. With the priority ratio of 3/2 between Task 5 and the rest of the 
tasks, the model determines it is optimal to avoid the translation penalty to worksite A, 
and instead complete a greater number of the lower priority tasks at worksites B and C. 


While this may seem counterintuitive, the objective score of the EPM timeline is notably 


oY 


better at 52.52 value units. Table 10 shows that the heuristic timeline, while including the 
highest priority task, omits twice as much cumulative task priority value as does the EPM 


solution. 


One area where the EPM solution is clearly inferior to the heuristic solution is in 
solve time. The heuristic solution to this very simplistic case is fairly intuitive and can be 
created very rapidly by hand, while the EPM takes nearly 11 hours to arrive at an optimal 
solution. There are many possible causes for this poor performance, one of which may be 
the large number of identical tasks included in this test case. All tasks at each worksite 
are exactly the same in all respects. As a result, the MIP suffers from "symmetry," for 
instance, the EPM solution shows Task 2 performed first and Task 4 second, but 
swapping the order of those two tasks results in the same objective score. Another factor 
is the relatively close priority value between the highest priority task and the remaining 
tasks. In this case the solution is clearly much less obvious than the heuristic approach 


might lead one to believe. 


Finally, we note that in authentic summary timelines, translations are not typically 
shown as separate activities. We have chosen to show them because they would assist an 
expert in assessing the efficiency of a timeline generated by the model. The tasks with the 
format "X Y-Z" in the summary timelines produced by the EPM are translations from 


location "Y" to location "Z." 
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Figure 10. Black-box test cases 1 and 1a timelines 
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3. Black-box Case 1a Configuration 


To see the effect of changing the priority of tasks, we increase the priority of Task 


5 to triple that of the other tasks, leaving all other parameters the same as in Case 1. 


4. Black-box Case la Results 


This test configuration results in the same heuristic solution used in Case 1. The 
EPM solution (shown at the bottom of Figure 10) now matches the heuristic timeline 
exactly (note that the ordering of tasks at a specific worksite is interchangeable since all 
have identical properties). The EVA proceeds directly to worksite A to perform the high 
priority Task 5, then on to worksite B to complete all tasks there, and finally to worksite 
A where one task is completed before returning to the airlock. This problem proves much 
easier for the EPM to reach an optimal solution, taking only 22 minutes. The priority 
difference in this situation is enough to make Task 5 too valuable to omit, which in turn 


speeds up convergence to an optimal solution. 


5; Black-box Case 1b Configuration 


To see the effect of varying the duration of tasks, we modify Case 1 by making all 
odd numbered tasks (except Task 1, the airlock egress) twice the duration of the even 
numbered tasks (i.e., even numbered tasks last 25 minutes, odd numbered tasks last 50 
minutes in this case). All other inputs and model parameters remain the same as those in 


Case 1. 


6. Black-box Case 1b Results 


The heuristic approach for this case consists of starting at the nearest worksite (C) 
and performing the shorter tasks first. Since it is clear that not all tasks will be performed, 
the only 50-minute task at worksite C (Task 13) is also performed before translating to 
worksite B. Task 5 is omitted because its longer duration and translation penalty 


outweighs its higher priority value. 


The EPM solution also begins at worksite C, but omits Task 13 to move on to 
worksite B and perform the shorter tasks there instead. Both timelines accomplish the 


62 


same number of tasks, but the EPM scores a slightly higher objective score by scheduling 
more tasks earlier (the model timeline completes five tasks in the same time it takes the 


heuristic to perform four). Figure 11 shows both timelines. 
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Figure 11. Black-box test case 1b timelines 
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cp Black-box Case 1c Configuration 


To see the effect of employing both crew members independently, we have 
modified Case 1 by making all odd numbered tasks solo (except Task 1, the airlock 
egress), leaving the even numbered tasks tandem. All other inputs and model parameters 


remain the same as those in Case 1. 


8. Black-box Case Ic Results 


One special note about this variant of the test case is that making half the tasks 
solo activities means there is time to complete all the tasks during a single EVA. Task 


selection is not a factor and the optimization is related to sequencing only. 


The heuristic solution for this case splits the crew immediately, sending EV1 to 
worksite A immediately to perform the highest priority task. EV2 translates to the nearest 
worksite (C), performs the only solo task at that location, then moves to worksite B to 
perform solo tasks until such time as EV1 can arrive. Both crew members continue to 
work on solo tasks until all are complete. In order to synchronize both crew members, an 
idle period must be incurred, after which they perform the tandem tasks together. Tandem 
tasks are completed first at worksite B, then worksite C. This solution yields an objective 
score of 43.42 value units. The heuristic and EPM summary timelines for this test case 


are shown in Figure 12. 


The EPM optimal solution exhibits a subtly different approach to this case. It does 
not split the crew right away, but instead sends them both to worksite C to perform the 
three tandem tasks. It then leaves EV1 at worksite C to perform the remaining solo task 
there (Task 13), while EV2 translates to worksite B to perform a solo task. Upon 
completion of Task 13, EV1 translates to worksite B. This sequencing allows the crew 
member's timelines remain synchronized, and tandem tasks at worksite B may be 
initiated without any preceding idle time. When all three tandem tasks at this location are 
complete, EV2 is sent to worksite A to perform Task 5, while EV1 completes the 
remaining solo tasks at worksite B. The 20 minute idle time that must occur somewhere 
in this scenario is thus left to the very end of the EVA. This solution results in an 
objective score of 43.43 value units. While that is only slightly higher than the heuristic 
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solution, the practical difference is fairly dramatic in favor of the EPM solution. (The 
small difference indicates the weighing factors in the optimization model may need be 
revisited to ensure this highly desirable solution is more clearly differentiated from other 
solutions, but we do not perform that change here.) The EPM solution trades performing 
Task 5 earlier for moving the idle time penalty to the end of the timeline. It is very good 
practice to move idle time as late as possible. MOD planners have a motto that says "you 
should always leave runway in front of you," meaning "do not wait to do something if 
you might later regret not using that time." That is exactly what the EPM has done by 
delaying the idle time as long as possible. The good sense of this approach can be 
demonstrated if we imagine that during the execution of the heuristic timeline, for 
example, Task 11 took 15 minutes longer than expected. EV2, who had been idle waiting 
for the completion of Task 11, now is faced with another 15 minutes of idle time before 
any other tasks can be performed. In some cases, such a scenario could seriously 


compromise the success of an EVA. 
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Figure 12. Black-box test case Ic timelines 
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07:00 


07:00 


9. Black-box Case 1d Configuration 


Case Id is intended to demonstrate the effect of defining allowable time windows 
for certain tasks. For this case we start with black-box test Case lc and add the constraint 
that all tasks at worksite C must take place during orbital night. This type of constraint 
could be imposed because, for example, the tasks (or their locations) dictate that solar 
array rotary joints be parked (rotation is temporarily stopped). We can envision a scenario 
in which the ISS power consumption profile requires all solar arrays to be in sun tracking 
mode during orbital day instead of a less efficient parked position. In such a situation, the 
array may only be parked at night and our EVA timeline must comply with the 


requirement. 


In addition to the timing constraint placed on the tasks at worksite C, we stipulate 
that Task 5 involves mating and/or de-mating toxic fluid connectors. This brings with it 
two more timing constraints: (1) the task can only occur during periods when the thermal 
environment has stabilized (to avoid large pressure changes in the fluid lines caused by 
temperature changes), and (2) the task's completion time must be such that sufficient time 
remains in the EVA to perform a bake-out if EMU contamination is suspected. The 
nature of Task 5 is not unprecedented; the ISS utilizes 100% anhydrous ammonia in its 
external thermal control system (NASA, 2011a) and connectors in this system must be 
manipulated during some EVA tasks, including some Big 12 contingency EVA tasks. In 
fact, leaks from exactly such a system during one of the pump module replacement EVAs 
in 2010 (NASA, 2010b) forced a bake-out to be executed to prevent toxic material from 


being introduced into the ISS cabin atmosphere (Harwood, 2010). 


As discussed in Chapter II, there is a sunrise and sunset every 45 minutes at the 
orbital velocity of the ISS, thus the tasks at worksite C must be parsed into the windows 
that correspond to night periods. Further, the thermally stable conditions needed for Task 
5 require that it not be scheduled during or immediately following a sunrise or sunset. 
The exact synchronization of the crew workday with sunset and sunrise times varies and 
is not typically known in exactitude until relatively close to the time of EVA execution. 
We estimate the night periods in terms of EVA PET windows in general, allowing for 


refinement when the true synchronization becomes clear. For this test case, we will use 
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the example orbital sunrise and sunset times in Table 9 to create our time windows. We 
have created the allowable time windows for Task 5 by assuming thermal stabilization 
takes 15 minutes following each sunrise and sunset and also included a five minute pad 
before sunrise and sunset as a safety margin. Recall that the latest bake-out time 
parameter, 6, is the latest PET at which toxic tasks must be completed. Here it is 


calculated using a 30-minute bake-out period and the orbital timing in the table. 


Orbital Day/Night Thermally Stable Latest Bake-out 
Times in PET (H:MM) | Periods in PET (H:MM) | Time, 5, in PET 


1:45 2:30 















Table 9. | Time parameters for black-box test case Id 


10. Black-box Case 1d Results 


Case 1d is a much more difficult one for a human planner to optimize because of 
the increased complexity. Utilizing basic heuristics, a feasible plan is created in relatively 
short order (40 minutes), but the EPM solution proves far superior. The model solution 
has a substantially higher objective score and again stands up extremely well to common 
sense analysis. The resulting summary timelines in Figure 13 demonstrate that while a 
human planner tends to think linearly about the problem, using small segments of idle 
time throughout the EVA to address the many timing constraints, the model is able to 
assess all possible options holistically. This allows the EPM solution to gather all the 
required idle time into one contiguous segment at the very end of the EVA, while the 
heuristic timeline includes five distinct idle periods. The result of the EPM's ability to 
consolidate this idle time is that it is able to accommodate all tasks and provide a full 35 
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minutes of usable time at the end of the EVA. The heuristic solution not only results in 
idle time that is not very useful due to its scattershot nature, but also forces the omission 


of one of the solo tasks at worksite B. 
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Figure 13. Black-box test case 1d timelines 
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11. — Black-box Testing Summary 


The black-box testing scheme confirms that the EPM produces credible results 
that match or exceed the results developed by a human (albeit not expert) planner in both 
objective value and common-sense assessment. The cases have been kept exceedingly 
simple in order to facilitate easy discussion and to allow a non-expert planner to make 
educated heuristic solutions in reasonably short time periods. Table 10 gives some 
comparative statistics related to the heuristic solutions to the test cases versus the model 


output. 


Priority Value of Idle Time 
Total (H:MM) / Type 


Black-box| Objective Value 
Test Case 


EVA Duration (H:MM) Solve Time (H:MM) 


Omitted Tasks 





Heuristic EPM Heuristic Heuristic EPM Heuristic] EPM 


0:00/na | 0:00/na 


0:00/na | 0:00/na 


0:00/na | 0:00/na 





0:20/ 0:20/ 
Condensed |Condensed 
mid-EVA at End 





0:35/ 
Condensed 
at End 


0:40 / 
Scattered 














* Solution uses CPLEX "opportunistic" parallel mode (all other cases employ deterministic parallel mode) 


Table 10. | Heuristic vs. EPM output comparison for black-box test cases 


An unexpected benefit of the test series is that it exposed performance issues with 
the EPM model. Table 10 includes the solution times for each case and reveals that 
solution times have a large variation, but tend to be lengthy. Trivial changes to model 
inputs, such as changing the priority value of a single task, sometimes results in dramatic 
and unpredictable variations in solve time - even in deterministic modes (see below). To 
address the overall speed of the model as formulated, several CPLEX performance tuning 
techniques, advised in Gregory (2008), have been attempted for some of the cases 


(notably Case Id). These techniques include the employment of up to seven parallel 
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threads in "opportunistic" mode, enabling aggressive probing, and utilizing the feasibility 
pump heuristic. Empirical evaluation of these modifications indicate some benefit is 
realized, although no attempt has been made to prove this fact. In using the parallel 
opportunistic mode (vice deterministic) solution times may vary even with identical 


inputs, making comparisons very difficult. 


The black-box test series also exposes that the consolidation and placement of idle 
time is one of the most substantial strengths of the EPM. During initial development of 
the optimization model, this was not necessarily a specific goal. Demonstrating this 
capability has not been the goal of black-box testing, but its emergence in the test results 
is significant. There are substantial benefits to this capability that have real value in EVA 


planning. 
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IV. PROOF-OF-CONCEPT EVALUATION 


The testing program described in Chapter III proves that mathematical 
combinatorial optimization can be used to create EVA timelines that include a 


comprehensive consideration of trade-offs and constraints. 


This chapter addresses the value of the EPM concept to develop timelines (and 
alternatives) for actual EVAs under current development, investigating the usefulness of 
an optimization model to alleviate some of the manual burden of creating initial and 
follow-on timelines. Although the number of test cases is very limited, we feel that these 
use-scenarios are representative of real-world planning situations and provide a valid 


basis for assessment of the EPM by expert planners. 
A. METHODOLOGY 


As discussed in Chapter III, evaluation of EVA timelines is largely subjective and 
by extension, evaluation of the EPM is also subjective. Understanding this, we have 
based our proof-of-concept assessment on (1) comparisons of EPM results to expert 


developed timelines and (2) expert opinions regarding EPM results and potential utility. 


We have been able to work with EVA planning experts to gather the necessary 
real-world data to have the EPM independently create two EVA plans in parallel with 
their traditional development so the two results can be compared. Recalling that the 
planning process requires many "what-if" assessments and revisions to arrive at 
consensus regarding which tasks will be included in an EVA, when they will occur, and 
the opportunity costs (e.g., which tasks will be omitted or moved), we have modeled and 


evaluated reasonable alternatives to each of the cases. 


We have also demonstrated the EPM to experts and obtained their opinions about 
its usefulness. The data are organized into sections, one each to describe the EVA 


development cases. Expert evaluations are summarized. 


The reader is cautioned that many tasks and locations involved in the EVA 


development cases contain acronyms which are not defined unless their definitions are 
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important to a basic understanding of the scenario. In most situations, this level of detail 
is not needed and the acronyms are simply part of the task title. To avoid confusion, task 


names are presented in italics when discussed in the text. 
B. LEE R&R EVA SCENARIOS 


The LEE is a component of the space station robotic manipulator system 
(SSRMS) that allows the robotic arm to grab onto grapple fixtures mounted on large 
ORUs and the ISS structure. There are two LEEs on the SSRMS, one on each end. The 
LEE R&R EVA is a contingency EVA being planned in the event a LEE fails and needs 
to be replaced. A spare LEE is pre-positioned at a stowage location on the exterior of the 
ISS. Since this is a single-purpose EVA, the planning problem is focused on ordering of 
and crew assignment to tasks. Essentially, the tasks are steps in a larger "procedure." The 
combined duration of all the tasks is short enough to fit within a 6.5-hour EVA, 
eliminating the need to omit any tasks due to lack of time. There are, however, extensive 
precedence relationships associated with the tasks. Additionally, there are many tandem 
tasks and tasks that involve movement from one worksite to another (i.e., different 
starting and ending location). This scenario has only one task which is constrained by 
time: /nstall LEE is assigned a bingo time of 5:05 PET. The full set of raw data for this 
EVA scenario, referred to as LEE R&R EVA (original), has been provided by the lead 
planner (F. Sabur, personal communication, June 27, 2012), and can be found in 
Appendix A. The EPM solve time for the two scenarios in this section are somewhat 
capricious, ranging from 18 minutes for the original scenario to several hours for the 


alternate scenario. 


There are very few possible feasible solutions to this EVA plan because of the 
high interaction level between all the tasks. Figure 14 shows the expert-generated, 
heuristic solution at the top and the EPM optimal solution in the middle. The EPM is 


successful in duplicating the expert solution. 


To add some variability to this planning problem, some additional tasks unrelated 
to the LEE R&R activity are added. This is commonly done by the program customer 


when an EVA has extra time available, as this one does. The modified scenario is 
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referred to as LEE R&R EVA (alternate). We perform a second EPM run with three new 
tasks included whose characteristics are based on three tasks that were requested to be 
added to ISS EVA 18 three weeks before its execution. The alternate task data are shown 
in Appendix B. The EPM is successful in accommodating one of the three additional 
tasks while extending the EVA by 36 minutes over the baseline case (see Figure 14, 
bottom). The inclusion of more tasks is limited primarily by the long distances between 


the worksites of the LEE R&R and the new tasks. 


Even though these results were fairly predictable given the constraint that all LEE 
R&R tasks must be completed before any of the new tasks could be scheduled, the EPM's 


ability to handle such cases has been successfully demonstrated. 
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Figure 14. LEE R&R EVA timelines 
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C. EVA "A" SCENARIOS 


EVA “A” is in the early planning stages for execution in 2013 or 2014. It is a 
more typical ISS assembly and maintenance EVA, driven by the need to accomplish a 
“to-do list” of tasks requested by the ISS program customer. This EVA represents a much 
different planning scenario than the LEE R&R. Here, the number and duration of 
requested tasks exceed the time available in a single EVA. All of the tasks are unique and 
independent, meaning no precedence relationships exist, and all tasks are solo. Two tasks 
requested for this EVA have time window constraints. The first, MTRA Install, is 
constrained by a four-hour thermal clock which starts at the beginning of the EVA; the 
second, MISSE 8 Retrieve, must be scheduled such that the first 20 minutes of the task 
occur during daylight (so that photographs can be taken). Another interesting aspect of 
this EVA is that since all the tasks are independent of each other, they all use a unique set 
of tools and equipment. Owing to limited carrying capacity, the crew members must 
translate to the Airlock to obtain the necessary tools and equipment at the beginning of 
each task and return there to drop them off at the end. As such, for most of the tasks, the 
beginning and ending location is the Airlock. This nuance of the tasks eliminates some 
flexibility the EPM could use to optimize their scheduling, but presents an interesting 
planning scenario. The full set of raw task data associated with this EVA, has been 
provided by the lead planners (J. Kagey & A. Battocletti, personal communication, 
August 23, 2012), and can be found in Appendix C. Figure 15 shows the current expert- 
developed timeline, labeled "heuristic" along with the EPM optimal solution. The EPM 
solve time for each of the scenarios in this section are highly satisfactory, ranging 
between two and four minutes. The subsections below detail some of the alternatives 


explored using EPM and the conclusions we have drawn from the results. 


1. Task Selection 


The first challenge of this planning scenario is to select the tasks that will be 
omitted from the plan since there is not enough time for all requested tasks. The expert 
planners have omitted two tasks, JEM-EF Fwd Camera and MLM Ethernet Cable Install, 


because they are the two lowest priority tasks. The EPM makes the same omissions due 
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in part to the lower priority value of the tasks, but also because of their relative length 
compared to similarly prioritized tasks. The Node3 Fwd/Aft CBM Prep and FGB PDGF 
Troubleshooting tasks, which have priority values just 10% greater than JEM-EF Fwd 
Camera, are scheduled instead - primarily because they have durations that are 25% and 


50% shorter, respectively. 


Zz. Priority Changes 


To examine the effect of changing priorities, we simulate the common situation of 
the program customer mandating that a specific task be added to an EVA in development. 
Typically, a negotiation occurs in these situations, and the ability to generate alternative 
timelines is important to inform stakeholder decisions. As described in Chapter I, 
developing these alternatives is time consuming for the planners and there usually is not 


adequate time to explore all possible options. 


Our simulation of this scenario involves one change to the previous EVA "A" 
model inputs: flagging JEM-EF Fwd Camera as mandatory. The bottom-most timeline in 
Figure 15 is the resulting optimal solution. An interesting effect of this change is that the 
EPM does not simply remove the next-lowest priority task from the plan. Instead it 
removes Z/ Jumper Route/Install, the fourth-highest priority task. In doing so, however, 
it replaces it with both the now-mandatory task and also the previously omitted MLM 
Ethernet Cable Install. If this outcome is also unsatisfactory to the program customer, 
other input parameters may be adjusted in turn, conveying the trade-offs and costs of new 


or updated requirements. 
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Figure 15. EVA "A" timelines (with first sunrise at 1:00 PET) 
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3. Day/Night Phasing 


One immediate advantage of utilizing the EPM is clear when considering the 
EVA "A" case: the ability to plan for the daylight constraints on the MISSE 8 Retrieve 
task. Since the execution date of the EVA is unknown at this time, it is impossible for the 
planners to know what the actual day/night timing will be with respect to PET (referred 
to as "phasing"). The planners have no choice but to ignore this factor for the time being 
and create their EVA plan as if the constraint did not exist. This approach carries the risk 
that when the actual day/night phasing becomes known, it could result in substantial 
disruption to the timeline. Such a perturbation must then be addressed at a relatively late 
stage of the planning process. The EPM allows the planners to examine a range of 
different day/night phasing to assess the impact it has on the optimal plan far earlier in 


the process. 


To investigate these effects, several day/night phasing cases have been tested. 
Figure 16 shows three timelines; all are optimal plans given their respective phasing, 
which is defined by the PET of the first sunrise during the EVA. Optimal timelines 
corresponding to first sunrises at PET of 30, 60, and 90 minutes are shown. A notable 
conclusion we can draw from these alternatives is that the heuristic solution, which 
schedules MISSE 8 Retrieve at 2:00 PET, is only feasible in one of these cases (sunrise at 
0:30 PET) and even in that case it is not optimal. This tells us that it is highly likely the 
planners will have to adjust the timing of this task eventually. Knowing that, it is 
important to observe that although the M/SSE 8 Retrieve task is the only one impacted by 
day/night phasing, the changes to the timeline extend well beyond just the timing of this 
one task. Without a capability to examine all the possible outcomes ahead of time, a 
human planner may be forced to wait for the phasing information to become available 
and then implement the suboptimal solution of simply sliding the task start time forward 
or back by enough minutes to make the lighting conditions acceptable. In taking this 


approach, they would be inherently diminishing the efficiency of the EVA. 
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Figure 16. EVA "A" timelines with varying day/night phasing 
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D. EXPERT EVALUATION OF EPM 


The EPM has been demonstrated for current and former EVA planning experts in 
order to solicit their opinions about its capabilities and usefulness. These demonstrations 
include the two EVA planning scenarios described in this chapter and static presentations 
of the EPM's features and results. Data have been gathered via expert survey 
questionnaires. The sample size is limited to four experts, in part by the small number of 
such experts available, and also due to ongoing EVA operations filling their schedules. 
As a result, this evaluation is not presented as a scientific study, but rather as a 


generalized indicator of the potential of the EPM tool and areas of improvement. 


The EPM has been well received by all four EVA planning experts surveyed. All 
indicate they would be inclined to utilize such a tool if it were available. They rate the 
timelines produced by the model as credible. One evaluator points to preterition in 
defining input data as a cause of deficiencies noted in the resulting plan. When asked to 
evaluate the usefulness of the EPM, experts rate it highest (average rating of 4.33 on a 
five-point scale) in three categories: (1) plan development and trade-space evaluations, 
(2) preparing for stakeholder negotiations, and (3) increased ability to assess alternatives. 
One expert noted: 

I would use the tool primarily during discussions with the ISS Program 

and Flight Director Office [a key stakeholder within MOD]. In my 

experience, they like to see many options and sometimes think arranging 

[the plan] a little different would create more [free time in the plan]. This 

tool would have made those demonstrations much quicker and less work 

involved for the EVA team. It may also convince upper level management 

that if you really want all those tasks completed, you need to schedule 

another EVA. 

Another expert acknowledges the potential of EPM to save time and expense in 
initial timeline development for specific types of EVAs, stating: 

For EVAs with one long task and highly constrained sequencing, the tool 

would not be as useful. But it would be useful in early EVA plan 

development when assessing how to schedule smaller tasks across a single 


or multiple EVA. In many cases the EVA planners scuba dive or perform 
a suited NBL run to evaluate proposed timelines. This can be an iterative 
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process as we develop a timeline. Having a good starting point would help 
reduce the number of iterations and could help illustrate specific 
trades/options. 


The quote above agrees well with our observations of the two distinct types of 
EVA planning scenarios described in this chapter. The LEE R&R EVA is a "highly 
constrained sequencing" scenario where the EPM output offers little more than matching 
the expert-developed timeline, while EVA "A" is a less constrained problem and 


demonstrates the power of the EPM to identify and assess alternatives. 


The EPM is rated lower in its perceived ability to save time in plan development, 
largely due to the data entry requirements and unpolished user interface. The user 
interface and manual entry of task data is noted in multiple expert evaluations as a 
weakness, one stating: "I think the longest pole is getting all of the initial data into the 
system. If it is not too long then I think this could be real [sic] helpful." Another 
respondent points out: 

Inputting the tasks and restrictions could be more user friendly. Being able 


to save these tasks to a database so future runs could pick and choose 
already developed tasks along with new items would also be helpful. 


Given the general reluctance to adopt new tools and embrace "automation" in 
processes that have historically been very hands-on and the fact that most of the 
deficiencies noted are related to the user interface and not the core capability of the EPM, 
the expert evaluations are a positive sign that EPM may become a helpful tool in the 


process of EVA planning. 
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V. FUTURE WORK 


The EPM has been developed to a proof of concept level as part of this research. 
The model has proven to be a usable tool that can help inform decision making during 
EVA planning even in its current form. There are many improvements that can, and 
should, be made to the model if its development is to continue with the goal of 


operational use. 
A. ADDITIONAL FUNCTIONALITY 


We use the term functionality to refer to the real-world planning considerations 
that are implemented by the model. Precedence relationships and asynchronous 
translation times are examples of two functions in the current EPM. There are many other 
functions that could be added to the model, some of which (e.g., task subdivision) are 
extraordinarily difficult problems. This section focuses on functionality that could be 
added in a follow-on revision rather than on the litany of capabilities that could be added 


in the more distant future. 


1. Tool Constraints 


Tools are an extremely important part of EVA planning and execution. The 
current EPM does not address tool requirements or constraints and adding this capability 
would be a major enhancement. This functionality could include a limit on how many 
tools can be carried at once, automatic addition of tool logistics tasks (for instance, 
translating to a tool box location to exchange tools), and ensuring that a unique tool is not 


needed by one crew member while the other crew member is using it elsewhere. 


2. Task Synergy 


Task synergy was mentioned in Chapter I as having a role in planning 
considerations. It was not implemented because in the current model architecture, all 
tasks considered are unique and individual. They can only be related to each other 
through precedence. In reality, tasks can be interlinked in different ways. For example, 


some tasks may have common steps which can yield substantial efficiency gains if the 


87 


tasks are performed adjacent to one another during the EVA. To envision this, consider 
three tasks whose first step is the removal of the same thermal cover. In the current 
model, each of the tasks would be entered with a duration that includes the removal and 
replacement of the thermal cover. The EPM would be aware of only one efficiency: that 
the tasks have the same location. However, in reality, if any one of the tasks is scheduled, 
the other two would be less time consuming when performed in immediate sequence with 
it. This type of relation is more difficult to implement than simple precedence because 
there is no need to stipulate the order in which they occur and the effect of them being 


scheduled "together" is a reduction in the duration of some of the tasks. 


a: Task Exclusivity 


Task exclusivity is another way in which tasks can be linked. This category 
involves groups of tasks that are mutually exclusive. For example, consider a case where 
three camera replacement tasks are possible. In the current model, they become 
independent tasks which have no relation to each other. However, if there are only two 
spare cameras available, then only two of the three tasks may be scheduled. The ability to 
eliminate a set of tasks from consideration if another task has been completed would be 
fairly simple to add in a future version of the EPM. Conversely, there may be some tasks 
that should always be performed together (although not necessarily in a specific order or 
concurrently). To add that type of functionality, a set of tasks would become mandatory if 


and only if another task or tasks have been scheduled. 


4. Robotics Integration 


Many, if not most, EVAs employ the ISS robotic arm. Robotics may be used to 
assist the crew in translating across long distances, help them reach difficult worksites, or 
allow the positing of large or massive objects. Since robotic arm integration is such an 
important part of EVA, its omission from the first version of the EPM leaves the potential 
for significant improvement. In most of the cases examined for this research, we have 
found that robotic arm integration can be mimicked by manipulating translation times for 
locations known to be associated with robotics-assisted tasks. This is a makeshift fix that 
is inadequate for longer-term use and/or more realistic employment of the EPM. 
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B. MODEL PERFORMANCE 


We have observed during black-box testing and in proof-of-concept runs of the 
EPM that its performance in terms of solution time is inadequate. EPM solve times are 
highly variable and increased dramatically with more complicated problems. For 
complex problems, solve times in the 24-hour range would not be unexpected. While this 
is not necessarily a problem for the generation of preliminary plans in the early phases of 
development, it could rule out use of the tool closer to, or in, real-time. Poor performance 
also works against the notion that an expert planner could use the model to generate a 
candidate timeline, evaluate it, change some parameters to adjust it, then re-run the model 
(and repeat). For that type of use scenario to be practicable, solve times would have to be 


in four-hour or less range (to facilitate multiple runs in a single work day). 


There are many options to improve performance of the model, some of which 
have been explored on a limited basis during black-box testing. A more focused effort on 
altering CLPEX settings to tailor performance to our specific model could yield better 
results. Exploring the use of other solvers should also be undertaken. Finally, the model 


could be revised to reduce complexity and/or strengthen the formulation. 
C; EASE OF USE 


To facilitate expert user acceptance and more widespread testing of future 
versions of the EPM, ease of use could be improved. In the current version, all input data 
are entered through Microsoft Excel templates via 10 independent files that must be 
populated with information. This should be reduced to a more economical set of input 
files or replaced by a user friendly interface for data entry, possibly supported by a 
database of existing tasks (and other problem data) as suggested by one of the surveyed 
planners. The addition of embedded input error checks and validations (for example, 
ensuring that a task's duration does not exceed its bingo time), would be a beneficial 


refinement. 


The output of the model is another area where usability can be enhanced. The raw 
output of the current EPM is comprised of one formatted text file showing the PET and 


tasks for each crew member and one Excel file that shows the tasks along with idle time 
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and translations. The former also provides a list of which input tasks have been omitted 
from the EVA. The Excel output file is used to more readily interface with an Excel 
Visual Basic macro that produces the graphical overview timelines seen in the figures of 
Chapters III and IV. These graphical views are commonly used by the planning experts 
and stakeholders. This process requires several intermediate steps, which could be 


streamlined to improve usability. 
D. INTEGRATION WITH OTHER AUTOMATED PLANNING TOOLS 


The possible integration of EPM with the task database, hierarchical task net 
information, and resource handling algorithms developed by TRACLabs (described in 
Chapter II) is an intriguing possibility. That work potentially holds the key to reducing 
the amount of manual data entry required for the EPM. It could also lead to enhancing the 
EPM's capabilities in areas highlighted above (e.g., tool constraint management) and in 
new areas such as detailed consideration of EMU consumables. Finally, it could enable 


the EPM to tackle the problem of task subdivision. 
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VI. CONCLUSION 


EVA planning is a highly complex process requiring a high level of expertise. We 
have developed the EPM, a MIP that optimizes the EVA planning sub-problems of task 
selection, crew assignment, and task sequencing. The EPM proves the concept that 
formal combinatorial optimization can be used to successfully improve the efficiency of 
EVA timeline development. The EPM has been tested extensively both to verify its 
functionality and its usefulness in real-world EVA planning situations. It has been 
evaluated by EVA planning experts who cited time savings in plan development and 


especially in assessment of alternatives as major reasons they would want to use the tool. 


We find that the EPM, while necessarily limited in its initial functionality, is able 
to provide complete and credible overview level timelines for two actual EVAs using 
only raw source data. We also find that it is capable of handling alternative planning 
scenarios commonly found in practice, including (1) the addition of extra tasks to a 
developed EVA plan, (2) a thorough analysis of orbital day/night phasing impacts upon 
EVA plans with tasks sensitive to such phasing, and (3) the changing of customer 
priorities during the planning process. Furthermore, the EPM has demonstrated enhanced 
trade-space evaluation by its ability to examine all feasible permutations of task selection, 
sequencing, and assignment and its creation of EVA plans as holistic entities rather than a 


series of sequential decisions as a human planner might. 


The EPM can be improved in multiple ways. Although no test case takes more 
than 24 hours to reach an optimal solution, the model's solve-time performance is found 
to be highly variable and unpredictable. For example, some test cases take more than ten 
hours to solve, while others require less than five minutes. We have identified several 
other improvement areas for the EPM, including added functionality and friendlier user 


interface. 


91 


THIS PAGE INTENTIONALLY LEFT BLANK 


92 


APPENDIX A: LEE R&R EVA RAW DATA 


This appendix provides data tables containing the raw input data used as EPM 
input for the LEE R&R EVA planning. These data have been gathered via personal 
communication with the lead EVA planner, F. Sabur (June 27, 2012). 


fe 3 w 
g 2 8 &£ 
BS les ese |(Ca. lee Wes pee 
o rt r= S ¢g 2 = % ma 00 
Beeler ee Slee geen ie ee ee 
PVGF_Release_from_EP 100 $5 6 0 0 0 0 0) 0 0 
P1_Worksite_Setup 100 30 33 0 0 0 0 0 0 0 
Remove_CLA 100 10 11 0 0 0 0 0 0 0 
Translate_Failed_LEE to _ELC1 100 30 30 0 1 0 0 0 0 0 
Spare_LEE Prep 100 45 50 0 0 0 0 0 0 0 
Stow_Failed_LEE_on_Temp Stow_Ring 100 25 25 0 1 0 0 0 0 0 
Retrieve_Spare_Lee 100 40 40 0 1 0 0 0 0 0 
Translate_Spare_LEE_to_P1 Worksite 100 30 30 0 1 0 0 0 0 0 
Install_CLA 100 10 11 0 0 0 0 0 0 0 
Install_LEE 100 30 30 0 1 0 0 0 1 305 
LEE_FSE_ Cleanup 100 9 10 0 0 0 0 0 0 0 
Remove_Failed_LEE 100 30 30 0 1 0 0 0 0 0 
Cleanup_Ingress 100 30 30 1 1 1 0 0 0 0 
Egress Setup 100 15 15 1 1 0 0 1 0 0 


Table 11. Task Data 
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Task 


Initial Location 


Final Location 


PVGF_ Release _from_EP HTV HTV 
P1 Worksite Setup Columbus_WIF3 P1 Worksite 
Remove_CLA P1_ Worksite P1_ Worksite 
Translate_Failed_ LEE to ELC1 P1 Worksite ELC1 
Spare_LEE Prep ELC1 ELC1 
Stow_Failed_LEE_on_Temp_Stow_Ring ELC1 ELC1 
Retrieve _Spare_Lee ELC1 ELC1 
Translate Spare_LEE_to_P1 Worksite ELC1 P1 Worksite 
Install_ CLA P1 Worksite P1 Worksite 
Install_LEE P1_ Worksite P1_ Worksite 
LEE_FSE Cleanup ELC1 ELC1 
Remove_LEE P1 Worksite P1 Worksite 
Cleanup_Ingress Airlock Airlock 
Egress Setup Airlock Airlock 
Table 12. Task Locations 
Predecessor Successor 


P1_Worksite_Setup 
Remove_Failed_LEE 


Remove_CLA 
Translate_Failed_LEE_ to ELC1 
Translate_Failed_LEE_ to ELC1 
Stow_Failed_LEE_on_Temp_Stow_Ring 


Remove_CLA 
Translate_Failed_LEE to _ELC1 
Spare_LEE Prep 
Translate_Failed_LEE_to_ELC1 
Retrieve Spare _Lee 


Retrieve Spare _Lee 
Retrieve Spare _Lee 
Translate_Spare_LEE to _P1 Worksite 


Remove_CLA 
Remove_Failed_LEE 


Translate_Spare_LEE to _P1 Worksite 


Install CLA 


Translate_Spare_LEE to _P1 Worksite 


Retrieve _Spare_Lee 


Stow_Failed_LEE_on_Temp_Stow_Ring 
Translate_Spare_LEE to _P1 Worksite 


Remove_CLA 
P1_Worksite_Setup 


Install CLA 

Install CLA 

Install CLA 
Install_LEE 

Install LEE 

LEE_FSE_ Cleanup 
LEE FSE_Cleanup 
LEE _FSE_Cleanup 
Remove_Failed_LEE 
Remove_Failed_LEE 


PVGF_Release_from_EP 
Stow_Failed_LEE_on_Temp_Stow_Ring 


Table 13. 


Remove_Failed_LEE 
Retrieve_Spare_Lee 


Precedence Relationships 
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Table 14.‘ Translation Times 


i 
wi Egress Setup 08 


Table 15. Task Time Windows 
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APPENDIX B: LEE R&R EVA RAW DATA (ALTERNATE) 


This appendix provides data tables containing the raw input data used as EPM 
input for the alternate LEE R&R EVA planning. These data have been gathered via 
personal communication with the lead EVA planner, F. Sabur (August 13, 2012). Only 


tables with changes from the baseline LEE R&R case are shown. 


Ss | ol N & € 2 So E 
o x a = 

Gee ea eeu) eee tee lee le | ee ee ees 

PVGF_Release_from_EP 100 5 6 0 0 0 0 0 0 0 
P1 Worksite Setup 100 30 33 0 0 0 0 0 0 0 
Remove_CLA 100 10 11 0 0 0 0 0 0 0 
Translate_Failed_LEE to ELC1 100 30 30 0 1 0 0 0 0 0 
Spare_LEE Prep 100 45 50 0 0 0 0 0 0 0 
Stow_Failed LEE on Temp Stow Ring 100 25 25 0 1 0 0 0 0 0 
Retrieve_Spare_Lee 100 40 40 0 1 0 0 0 0 0 
Translate_Spare_LEE_to_P1 Worksite 100 30 30 0 1 0 0 0 0 0 
Install_CLA 100 10 11 0 0 0 0 0 0 0 
Install_LEE 100 30 30 1 1 0 0 0 1 305 
LEE_FSE_Cleanup 100 9 10 O 0 0 0 0 0 0 
Remove _Failed_LEE 100 30 30 0 1 0 0 0 0 0 
Cleanup_Ingress 100 30 30 1 1 1 0 0 0 0 
Egress Setup 100 15 15 1 1 0 0 1 0 0 
PMA2_Cover_Install 60 20 20 0 1 0 0 0 0 0 
SSRMS_Boom_Camera_Replace 65 35 35 0 0 0 0 0 0 0 
Retrieve_Mast_Camera 50 15 15 0 0 0 0 0 0 0 


Table 16. Task Data 
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Task 


PVGF_Release_from_EP 

P1_ Worksite Setup 

Remove_CLA 

Translate_Failed_LEE_ to ELC1 
Spare_LEE Prep 
Stow_Failed_LEE_on_Temp_Stow_Ring 
Retrieve Spare _Lee 
Translate_Spare_LEE to _P1 Worksite 
Install CLA 

Install_ LEE 

LEE_FSE_Cleanup 
Remove_Failed_LEE 

Cleanup_Ingress 

Egress Setup 

PMA2_Cover_Install 
SSRMS_Boom_Camera_Replace 
Retrieve _Mast_Camera 


Table 17. 


Initial Location 


HTV 


Columbus_WIF3 


P1_ Worksite 
P1_ Worksite 
ELC1 
ELC1 
ELC1 
ELC1 
P1_ Worksite 
P1_ Worksite 
ELC1 
P1_ Worksite 
Airlock 
Airlock 
PMA2 
SO_F2_WIF22 
MT_WS4 


Task Locations 
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Final Location 


HTV 
P1_ Worksite 
P1_ Worksite 
ELC1 
ELC1 
ELC1 
ELC1 
P1_ Worksite 
P1_ Worksite 
P1_ Worksite 
ELC1 
P1_ Worksite 
Airlock 
Airlock 
PMA2 
SO_F2_WIF22 
MT_WS4 


Predecessor Successor 


P1_Worksite_Setup Remove_CLA 

Remove_Failed_LEE Translate_Failed_LEE_ to ELC1 
Remove_ClA Translate_Failed_LEE_ to ELC1 
Translate_Failed_LEE to ELC1 Stow_Failed_LEE_on_Temp_Stow_Ring 
Spare_LEE Prep Retrieve Spare Lee 
Translate_Failed_LEE_to ELC1 Retrieve Spare _Lee 

Retrieve Spare Lee Translate_Spare_LEE to _P1 Worksite 
Remove_CLA Install_ CLA 

Remove_Failed_LEE Install CLA 
Translate_Spare_LEE to _P1 Worksite Install CLA 

Install_ CLA Install_LEE 

Translate_Spare_LEE to _P1 Worksite Install_LEE 

Retrieve Spare Lee LEE_FSE_Cleanup 


Stow_Failed_LEE_on_Temp_Stow_Ring LEE _FSE_Cleanup 
Translate_Spare_LEE to _P1 Worksite LEE _FSE_Cleanup 


Remove_CLA Remove_Failed_LEE 
P1 Worksite_Setup Remove_Failed_LEE 
PVGF_Release_from_EP Remove_Failed_LEE 
Stow_Failed_LEE_on_Temp_Stow_Ring Retrieve_Spare_Lee 
Install_LEE SSRMS_Boom_Camera_Replace 


Table 18. | Precedence Relationships 


Airlock HTV ELC1 P1_Wrkst Col_WIF3 PMA2 MT_WS4 SO _WIF22 
Airlock 0 13 10 8 10 13 32 34 
HTV 13 0 20 10 2 2 31 33 
ELC1 10 20 0 10 20 22 37 41 
P1_Wrkst 8 10 10 0 10 13 17 21 
Col_WIF3 10 2 20 10 0 2 32 34 
PMA2 13 2 22 13 2 0 34 36 
MT_WS4 32 31 37 27 32 34 0 24 
SO_WIF22 34 33 41 31 34 36 24 0 


Table 19. ‘Translation Times 
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APPENDIX C: EVA "A" RAW DATA 


This appendix provides data tables containing the raw input data used as EPM 
input for the EVA "A" planning. These data have been gathered via personal 
communication with the lead EVA planners, J. Kagey and A. Battocletti (August 23, 
2012). 


= = w 

> = Ss g = x E Sp E 

ae ie ede AS 2 2 eae ie 

Egress Setup 1 30 30 1 1 0 0 1 0 0 
MBS_Mast_CLPA_RR 100 90 90 0 0 0 0 0 0 0 
MTRA_Install 90 150 150 0 0 0 0 1 0 0 
MISSE_8 Retrieve 95 60 60 0 0 0 0 1 0 0 
Node3_Fwd_Aft_CBM_Prep 50 45 45 0 0 0 0 0 0 0 
Route_1553 Cable 55 60 60 0 0 0 0 0 0 0 
Remove_MBSU_MLI 60 45 45 0 0 0 0 0 0 0 
Cleanup_Ingress 0 45 45 1 1 1 0 0 0 0 
Z1_ Jumper_Route_Install 8 75 75 0 0 0 0 0 0 0 
FGB_PDGF_Troubleshooting 50 30 30 0 0 0 0 0 0 0 
JEM_EF_Fwd_Camera 45 60 60 0 0 0 0 0 0 0 
MLM_Ethernet_Cable Install 40 65 65 0 0 0 0 0 0 0 


Table 20. Task Data 
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Airlock 
ELC2 
MT 
Node3 
Z1 

JEM 
FGB 


Nodel 


Task 


Initial Location 


Final Location 


Egress Setup Airlock Airlock 
MBS_Mast_CLPA_RR Airlock Airlock 
MTRA_Install Airlock Airlock 
MISSE_8 Retrieve Airlock Airlock 
Node3 Fwd_Aft_CBM Prep Node3 Node3 
Route_1553 Cable Airlock Airlock 
Remove_MBSU_MLI Airlock Airlock 
Cleanup_Ingress Airlock Airlock 
Z1 Jumper_Route_Install Airlock Airlock 
FGB_PDGF_Troubleshooting FGB FGB 
JEM_EF_Fwd_Camera Airlock Airlock 
MLM_Ethernet_Cable_Install Airlock Airlock 
Table 21. Task Locations 
Predecessor Successor 
Egress Setup Cleanup_Ingress 
Table 22. Precedence Relationships 

Airlock ELC2 MT Node3 Z1 JEM 

0 12 8 5 8 15 

12 0 8 17 16 20 

8 8 0 13 16 10 

5 17 1 0 5 15 

8 16 16 5 0 20 

15 20 10 15 20 0 

10 22 18 5 8 20 

5 17 13 2 5 20 

Table 23. Translation Times 
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ist Sunrise @ 0:30 PET ist Sunrise @ 1:00 PET ist Sunrise @ 1:30 PET 


wl 
wl 
wl 
w2 
w3 
w4 


tmin tmax tmin tmax tmin tmax 
Egress Setup 0 30 0 30 0 30 
MTRA_Install 0 240 0 240 0 240 
MISSE_8 Retrieve 30 115 60 145 1 86 
MISSE_8 Retrieve 120 205 150 235 90 175 
MISSE_8 Retrieve 210 295 240 325 180 265 
MISSE_8 Retrieve 300 385 330 390 270 355 


Table 24. 


Task Time Windows (for three day/night phasing cases) 
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